# Installing TEACH Mission Control with Hermes

## First understand the package

This ZIP is an implementation kit. Verification proves that the supplied instructions and sources are intact; it does not prove that the target application has been built, installed, connected, or tested.

Current target status: `not_operational_build_required`.

## Prerequisites

- A private local folder with enough space for a work copy, dependencies, application data, backups, and a release candidate
- A current Hermes environment capable of reading the entire package
- Python 3 for the bundled verifier
- A supported application runtime and package manager, to be detected during preflight rather than assumed
- Permission to install any proposed dependency or make any proposed network request
- Public or synthetic test material only

Do not use PHI, patient narratives, learner records, submissions, grades, accommodations, conduct or clinical-performance records, secure assessment content, employee records, confidential institutional information, credentials, tokens, or secrets during setup.

## Step 1 — preserve and verify

Keep the unchanged original ZIP immediately beside the extracted package folder. From the extracted package root, verify both the working copy and authoritative outer-ZIP metadata:

```text
python3 tools/verify-build-kit.py --package . --zip ../TEACH-Nurse-Educator-Instructional-Designer-Mission-Control-Hermes-Build-Kit-v1.0.0.zip
```

Stop if verification fails. Do not repair an immutable source in place.

## Step 2 — give the complete package to Hermes

Use a new or verified-isolated implementation workspace. Give Hermes the entire package, then say:

> Open `GIVE-THIS-PACKAGE-TO-HERMES.md`, verify the package, display `PROCESSING_MESSAGE.md`, and begin with read-only preflight. Show one Implementation Activation Card and wait for my decision before changing anything.

Do not split the program or provide only screenshots or selected Markdown files.

## Step 3 — review the Activation Card

The card must show:

- immutable input hashes and the proposed copy-on-write path;
- detected runtimes, dependencies, licenses, downloads, and network use;
- application, database, attachment, log, export, and backup paths;
- loopback URL, authentication, session, and secret approach;
- the three role adapters and five protected workspaces;
- learner-data exclusion and no-PHI admission controls;
- Core Four, empty fifth launcher, 20 inactive powers, 18 Preview workflows, and 24 templates;
- Hermes capabilities actually detected, not assumed;
- all agents disabled at P0;
- all external actions, connectors, sharing, and schedules off;
- build, test, accessibility, clean-install, backup, update, rollback, removal, and uninstall plans;
- blockers, unsupported items, checkpoints, and the exact resume command.

Choose **Approve**, **Revise**, or **Cancel**. Approval applies only to the exact card. It does not authorize learner or patient data, institutional deployment, external release, LMS changes, messages, publication, grading, or agent/power activation.

## Step 4 — follow the checkpoints

- **S0 — Freeze and copy:** verify inputs, record environment, and create an approved work copy.
- **S1 — Offline core:** implement authentication, durable local records, five workspaces, mission-loop CRUD, restart, export/import, and backup/restore.
- **S2 — Educator + TEACH domain:** implement the three adapters, Core Four, 20/18/24 catalogs, governance, accessibility, Guide, and 169 canonical checks.
- **S3 — Genuine AI and bounded agents:** implement capability-driven Hermes integration, real streaming and cancellation, source-aware evidence, memory controls, and separately approved one-run agent support.
- **S4 — Release assurance:** execute the complete 433-record ledger, clean-install and recovery tests, package the app, and produce the final report.

Save every receipt. A receipt must identify actual changes, commands, dependency/network use, data and migrations, executed tests, process identifiers, blockers, rollback point, and next step.

## Step 5 — accept the handoff

Use `implementation/HERMES-FINAL-HANDOFF-REPORT-TEMPLATE.md`. Verify the reported package hash, version, clean-install evidence, tested platforms, data locations, launch/stop/diagnostic commands, backup/restore proof, update/rollback proof, uninstall behavior, limitations, and readiness state.

Do not accept “Operational” unless the exact release passed every applicable core criterion and a genuine configured backend streamed and cancelled through the packaged UI.

## First launch of the built application

1. Confirm the URL is loopback-only and matches the handoff.
2. Create the owner credential; store recovery information privately.
3. Select Nurse Educator, Instructional Designer, or Hybrid/Faculty Developer, then declare the active task-level hat.
4. Review the learner-data, no-PHI, privacy, authority, and external-action boundaries.
5. Preview and approve only accurate derived Mission Profile fields.
6. Confirm all 20 powers remain inactive, all 18 workflows remain Preview, agents are P0, and the fifth launcher is empty.
7. Adopt, edit, or clear synthetic Starter content.
8. Start one low-risk mission using public, synthetic, or educator-owned nonsensitive information.

## Backup and restore

Before relying on the app, create a versioned local backup and prove restoration into a temporary location. Backups must remain scoped: private educator data never enters an institutional backup, and one institutional store never enters another. Protect backup files as carefully as the records they contain.

## Update and rollback

Before an update:

1. stop the application;
2. verify the update package;
3. record the current app and schema versions;
4. create and test a matched backup;
5. preview migrations and rollback conditions;
6. apply each migration exactly once;
7. rerun integrity, learner-data, no-PHI, accessibility, restart, backup/restore, and acceptance tests.

If the update fails, stop. Preserve redacted diagnostics, restore the matched application and database backup, verify integrity, and record the rollback. Never open a newer database with an older binary unless compatibility was tested.

## Pause, reset, overlay removal, and uninstall

- **Pause All:** stop queued and active AI work without deleting records.
- **Safe Reset:** preview a return to private synthetic mode, session-only memory, no connectors/sharing/actions, Core Four, empty fifth, inactive powers, and P0 agents.
- **Overlay removal:** remove TEACH-specific views, records, powers, and permissions while preserving compatible foundation and unrelated owner data.
- **Rollback:** restore a verified matched release and backup.
- **Uninstall:** stop services, preview retained/deleted paths, offer a scoped backup, remove application files and launchers, and report anything that remains.

Local uninstall cannot erase copies already exported, backed up by the operating system, or sent to external systems.
