[sudoshi]

#92 built an independent Nightingale product foundation. It was superseded by
#101, which renamed the existing patient app in place — that app was already
feature-complete and is what ships to TestFlight today. #92's app scaffolds are
therefore not adopted: 19 iOS files with no features and no networking, so
taking them would have replaced a working patient application with a launch
screen.

Its backend governance layer, documentation, and privacy work are a different
matter, and are salvaged here.

Activation and disclosure gates

20 pure classes plus tests. The activation gate evaluates five independent,
conjunctive preconditions — clinical approval, content release, feature
activation, pilot enrollment, source connector — any one of which holds the
whole evaluation. No route, container binding, config reader, source query,
audit writer, or native caller.

This models exactly the separation that was missing when tracing why no
projection reaches a patient: clinical approval and content release as separate
conditions rather than a single flag.

A config collision this avoids

#92 adds a 44-line config/nightingale.php declaring a foundation namespace.
main already has a 271-line config/nightingale.php — the live file the
deployed backend reads for 48 environment variables. Merging #92 as-is would
have had one silently replace the other. The foundation keys are merged into
the existing file under a marked section instead; config:show confirms every
serving value is unchanged.

Privacy manifest, corrected

Neither shipped iOS app had a PrivacyInfo.xcprivacy. Apple requires one for
App Store submission. #92's declared an empty NSPrivacyCollectedDataTypes —
true of a foundation with no networking, false for an app that authenticates
and exchanges clinical content. Copying it verbatim would have filed an
inaccurate declaration, which is worse than filing none.

Verified against source: UserDefaults is the only required-reason API
category in the target, so CA92.1 alone is correct, and NSPrivacyTracking
false is already enforced by check-no-tracking-technologies.sh. The
collected-data entries are deliberately conservative and carry an in-file note
that they need product and privacy sign-off before submission.

63 governance documents

Threat and hazard model, privacy release controls, accessibility layout and
language-readiness matrices, dependency inventory, contract ownership matrix,
identity recovery and protected-state decisions, background rights review,
controlled pilot manifest, and the product identity checklist.

Nine cite nightingale/iosApp paths that were never adopted. Rather than edit
sixty-three documents or drop the nine, the README carries a substitution table
and states which parts of #92 were salvaged and which were not.

The guard that should have existed

scripts/ci/verify-app-identity-uniqueness.sh fails CI when two applications
declare the same identifier within a platform. Per-platform, not global — one
product legitimately declares the same identifier once for iOS and once for
Android.

Verified both directions: passes on the current tree (7 iOS, 2 Android), and
exits 1 naming all four collisions against a reconstruction of the
#92-plus-#101 merged tree. That is the failure that should have happened in
July, before either shipped.

Verification

• 23 salvaged unit tests pass (149 assertions)
• Patient suite still passes 301 tests (4,290 assertions)
• xcodegen bundles the privacy manifest; xcode-project, patient-boundary, and
  tracking-technology guards pass
• config:show nightingale confirms live values unchanged

Not carried across

nightingale/iosApp, nightingale/androidApp, and every deletion of
hummingbird/…PatientApp.