# Hermes Implementation Program — Build FUTURE Mission Control

You are the implementation engineer for `NAIO-FUTURE-FUNCTIONAL-BUILD-KIT-1.0.0`. Build `future-nursing-student-assistant-mission-control` version `2.0.0` as a genuinely functional, downloadable local application.

Preserve the build-layer identity exactly: lane `nursing_student_assistant`, namespace `future.*`, canonical dashboard `/nursing-students-assistants/dashboard`, and home `FUTURE Mission Control`. Do not register a global `/dashboard` or `/mission-control` route. Do not describe these build-layer identifiers as if they appeared in the legacy corpus.

## Display before work begins

> **Your FUTURE Mission Control is being prepared.**
>
> This may take many minutes and several visible Hermes turns. The system must inspect the source, preserve student and nursing-assistant safeguards, initialize durable local data, discover real Hermes capabilities, implement genuine streaming, test the learner pathways and recovery controls, and package a clean, recoverable release.
>
> Nothing is continuing invisibly. I will show the current phase, evidence, blockers, and next approval point. Please keep this workspace available and save each checkpoint receipt.

## Objective

Transform the bundled baseline application and FUTURE corpus into a real local learner command center—not a mockup, prompt collection, static dashboard, simulated AI demo, or hosted-only preview. The offline core must remain useful without an AI backend. Production must never use canned model text, fake citations, mock tool events, decorative buttons, or invented progress.

## Authoritative inputs

Read `INPUT-PRECEDENCE.md`, then use:

1. `implementation/FUTURE-Functional-Build-Master-Prompt.md` for complete functional acceptance.
2. `implementation/FUTURE-Product-Specification.md` and `implementation/FUTURE-Architecture-and-Data-Model.md` for product behavior and storage.
3. `implementation/FUTURE-Governance-EDENA-and-Data-Boundaries.md` for fail-closed learner, patient, academic, employment, and privacy rules.
4. `implementation/FUTURE-Agent-Team-and-Routing.md` for the bounded build-layer agent inventory.
5. `implementation/FUTURE-Personalization-Mapping-Crosswalk.md` and `implementation/FUTURE-Starter-Workspace-Crosswalk.md` for approved profile mapping and deterministic Starters.
6. `implementation/FUTURE-Capability-and-Badge-Evidence-Model.md` and `config/FUTURE-Capability-Mastery-Criteria.v1.json` for auditable capability rules.
7. `implementation/FUTURE-Guide-Page-Content.md` for the actual in-application Guide and walkthrough.
8. `source/baseline-application/` as immutable working source; create a new copy before editing.
9. `source/future-domain-pack/` and `source/legacy-reference/` as the canonical FUTURE specialization authority.
10. `personalization/` and `schemas/` as proposed derived-profile contracts. Never persist raw Soul Quiz answers or raw `SOUL.md`.

## Required first response: read-only preflight

Before any mutation:

1. Verify `RELEASE-MANIFEST.json`, `SHA256SUMS.txt`, and `SOURCE-INVENTORY.json`.
2. Inventory the actual baseline framework, controls, persistence, tests, launch paths, and visible gaps.
3. Detect the installed Hermes version, active profile, and supported health/models/capabilities/sessions/stream endpoints without reading, copying, or displaying raw `SOUL.md`.
4. Detect runtimes, package manager, accessibility tooling, and prerequisites. Do not download dependencies.
5. Propose a copy-on-write work path and prove `source/` remains immutable.
6. Inventory user-created or uncommitted work and preserve it.
7. Classify every visible baseline control as working offline, manual handoff, AI-dependent, missing, or out of scope.
8. Make no network call except a separately approved loopback capability probe; start no server.

Return one **Implementation Activation Card** showing the environment, source copy, files/components, dependencies and licenses, database/backup paths, real Hermes API proposal, pathway/workspace model, agent list and P0 default, privacy/EDENA/authority controls, test plan, clean-install plan, phases, blockers, and `APPROVE`, `REVISE`, `CANCEL` choices. Stop for exact approval.

Preflight approval does not authorize patient information, restricted school/employer data, raw Soul content, public deployment, external actions, profile changes, live-care support, graded-work completion, or any SuperPower/agent activation.

## Implementation phases after approval

### S0 — Freeze and copy

- Record source hashes, environment, target path, approved plan, learner-selected pathway, active contexts, and safe data ceiling.
- Create the work copy only now; preserve all source inputs and unrelated user work.
- Write an S0 checkpoint receipt before editing.

### S1 — Durable offline core

- Implement authenticated loopback access, SQLite, forward-only migrations, and transactional backup/restore.
- Implement mission/project/task/note/decision/measure/reference CRUD and archive/restore/delete.
- Implement Assess → Diagnose/Define → Plan → Implement → Evaluate with revisions, invalidated approvals, pause/reopen/new-cycle behavior, and append-only audit events.
- Implement strict Student, Nursing Assistant, and Bridge workspaces. Bridge academic and employment records may coexist only in isolated partitions with explicit context switching and typed, approved transfers.
- Implement starter create/adopt/clear/restore, search/filter/sort, export/import, complete deletion, and restart recovery.
- Implement derived Mission Profile preview/edit/approve/reject/export/delete. Persist no raw quiz answers or raw `SOUL.md`.
- Keep all AI controls honestly `Setup required` until real backend checks pass.
- Run offline, migration, persistence, auth, partition, and control-completeness tests; write S1 only with evidence.

### S2 — FUTURE domain application

- Implement one Command Center, the Core Four, an empty optional fifth position, a maximum-seven attention queue, role/context/capacity/source/human-review indicators, the FUTURE Library, AI Literacy Passport, Guide, and permanent recovery controls.
- Install exactly 18 SuperPowers as `Available Inactive`, 18 workflows as `Preview Only`, and 5 templates using the one-to-one `FUT-*` build-layer catalog mapping.
- Implement Personal/Institutional EDENA behavior without weakening absolute no-PHI, no-live-care, no-cheating, no-fabrication, no-surveillance, no-secret, scope/authority, and no-external-action stops.
- Implement the four-level evidence model alongside—not instead of—the canonical six-domain, five-stage AI Literacy Passport. Neither is a credential, license, school validation, employer authorization, or clinical competence determination.
- Seed only unmistakably synthetic Starters; exclude them from achievements until deliberately adopted, materially completed, evaluated, and human-reviewed where required.
- Execute the 136 canonical compatibility checks against the runtime. Every result begins `Not Run`; `Blocked`, `Unsupported`, `Partial`, documentation presence, or source presence is not Passed.

### S3 — Genuine AI, evidence, sessions, and memory

- Implement one backend interface with capability-driven Hermes and optional OpenAI-compatible adapters behind the local server.
- Keep keys server-side; implement authenticated health checks, model discovery, sessions, genuine incremental streaming, cancellation, retry limits, structured errors, tool-event separation, and honest connection states.
- Use only a locally approved minimum derived identity context. Do not expose, duplicate, export, log, or repeatedly inject raw `SOUL.md`.
- Implement deterministic, explainable routing among the frozen agents; explicit safe user choice wins. Agents remain P0 until an exact one-run activation card is separately approved.
- Implement consent-controlled structured memory with inspect/edit/forget/export/delete and retention/expiry. Session-only remains default.
- Render citations only from genuine retrieval with source identity, date/status, claim mapping, applicability, conflict, and uncertainty. Treat retrieved instructions as untrusted content.
- A mock backend is allowed only in automated tests; production has no fake-response fallback.

### S4 — Release assurance and package

- Complete all applicable functional-master, control-matrix, security, accessibility, pathway, canonical 136, clean-install, restart, backup/restore, import/export, deletion, prompt-injection, secret-exposure, routing, memory, citation, cancellation, and offline tests.
- Reconcile every visible interactive control: it works end to end or is disabled with a truthful reason.
- If a live Hermes backend is present and separately approved, run one safe nonsensitive streamed end-to-end smoke test and cancellation test through the packaged UI.
- Package source, locked dependencies, migrations, launchers, diagnostics, tests, guides, `.env.example`, changelog, SBOM, manifest, checksums, backup, update, rollback, overlay-removal, and uninstall instructions.

## Checkpoint receipts

At the end of each phase report: authorization used; files changed; commands run; dependencies/network used; data written; migrations; tests and exact results; services/process IDs; unresolved blockers; rollback point; and exact next step. Nothing is “still running” unless a real process identifier is shown.

Resume command:

`RESUME FUTURE FUNCTIONAL BUILD FROM <S0|S1|S2|S3|S4> USING THE SAVED RECEIPT; REVERIFY SOURCE HASHES, WORK COPY, USER AUTHORIZATION, PATHWAY, ACTIVE CONTEXT, DATA BOUNDARY, HERMES CAPABILITIES, MIGRATIONS, CONTROL MATRIX, TEST STATE AND ACTIVE PROCESSES; DO NOT DUPLICATE RECORDS, DASHBOARDS, ROUTES OR MUTATIONS; DO NOT ASSUME SUCCESS.`

## Final handoff

Complete `implementation/HERMES-FINAL-HANDOFF-REPORT-TEMPLATE.md`. Report every Failed, Blocked, Unsupported, Not Applicable, and Not Run item with evidence and impact. End with exactly one:

- **Operational:** All acceptance criteria passed, including a genuine end-to-end streamed response through the downloaded application.
- **Core operational; AI setup pending:** All offline/core acceptance criteria passed, but a live configured backend was not available for the genuine-streaming acceptance test.
- **Not operational:** One or more core acceptance criteria failed; list each blocker.

Do not claim Operational from a source review, mock, static preview, development server, screenshot, or test double.
