Harden project identity and Mission Control runtime integrity after Doctor changes

[eyeinthesky6]

Summary

Fix three verified integrity gaps in the Doctor / Mission Control path:

1. inconsistent parsing of duplicate keys in project.yaml;
2. collisions when separate repository roots use the same project_id;
3. reuse of a stale Mission Control process after the source checkout changes.

This is not a new autonomy or orchestration feature. Codex Coordinator already provides goal decomposition, bounded durable tasks, native messaging, recovery, heartbeat return paths, user-authority protection, and consolidated outcomes. This issue is about making identity and runtime verification fail-closed everywhere.

Branch / sequencing note

The defects below were verified against the head of draft PR #18 (codex/doctor-mission-control-hardening). Preserve that work. Implement this issue on top of PR #18 or after it is merged; do not recreate or replace its deterministic Doctor and opt-in Deep Review design.

---

Defect 1 — marker parsing is not consistently fail-closed

Current behaviour

The SessionStart hook's marker reader requires exactly one occurrence of a requested key and rejects an ambiguous marker.

By contrast:

• apps/mission_control/collector.py::_parse_simple_yaml
• apps/mission_control/doctor_scan.py::_simple_yaml

store parsed values in dictionaries and silently let later duplicate keys overwrite earlier values.

A malformed project.yaml can therefore be rejected by the canonical SessionStart path while Mission Control or Doctor still treats it as enabled and valid.

Required change

• Introduce one bounded, deterministic, dependency-free marker parser used by SessionStart, Mission Control, and Doctor, or enforce exactly equivalent strict behaviour in all three paths.
• Reject duplicate canonical keys, invalid UTF-8 where relevant, oversized markers, unsupported schema, malformed values, and ambiguous enablement.
• Fail closed: an invalid marker must never grant coordination authority, enable routing, or be displayed as healthy.
• Preserve the current no-network and no-model properties.
• Keep error output bounded and safe for local display.

---

Defect 2 — duplicate project_id values can collide across roots

Current behaviour

Doctor currently maps loaded projects by projectId when deduplicating and writing findings. Two different enabled repository roots with the same project_id can overwrite each other in that map.

Consequences may include:

• a finding being checked against the wrong project's existing fingerprints;
• a finding being written to the wrong local inbox;
• one project disappearing from Doctor's internal lookup;
• Mission Control presenting ambiguous project identity.

This is especially important because cross-project contamination is a core failure class that Coordinator is designed to prevent.

Required change

• Treat the internal project identity as at least canonical root + project_id; never use project_id alone as a dictionary or routing key across roots.
• Detect two or more enabled roots that declare the same project_id.
• Emit a deterministic high-severity DUPLICATE_PROJECT_ID finding for each affected root without confusing or overwriting their inboxes.
• Refuse ambiguous cross-project routing or finding placement until the identity is repaired.
• Mission Control must keep the roots distinct even when their display IDs match.
• Do not expose literal local paths in public-facing or model-review packets. Local diagnostic output may use a bounded safe root label or hash where needed.
• Existing single-project behaviour must remain unchanged.

---

Defect 3 — the Windows launcher may reuse stale Mission Control code

Current behaviour

apps/mission_control/start-background.ps1 reuses a process when:

• it owns port 4317;
• its command line contains -m apps.mission_control;
• /api/health returns HTTP 200.

It does not verify that the running process came from the current checkout or release. After an update, the launcher can reuse a healthy process running old code.

Required change

• Add a bounded runtime identity to /api/health, including enough deterministic information to verify compatibility, for example:
  • release/package version;
  • Mission Control API/schema version;
  • non-sensitive source/runtime fingerprint.
• Have start-background.ps1 calculate the expected identity for the checkout it is launching from.
• Reuse an existing process only when the health response matches the expected identity.
• If the listener is Mission Control but the identity differs, stop the stale process safely and start the current checkout.
• Continue refusing to kill unrelated applications that happen to use port 4317.
• Preserve the existing no-duplicate-browser-tab and readiness-check behaviour.
• Keep the health payload free of secrets and unnecessary local path disclosure.

---

Required regression tests

Add release-blocking tests for at least these cases:

Marker parser consistency

• duplicate project_id key;
• duplicate coordination_enabled key with conflicting values;
• duplicate schema or cross-project policy keys;
• unsupported schema;
• oversized or malformed marker;
• SessionStart, Mission Control, and Doctor all fail closed consistently.

Cross-root identity

• two enabled temporary roots with the same project_id remain separate internally;
• Doctor produces the duplicate-identity finding for both roots;
• each finding is deduplicated and written only to its correct local inbox;
• no project_by_id-style overwrite is possible;
• Mission Control returns distinct project records and task associations.

Runtime fingerprint

• a matching Mission Control runtime is reused;
• a mismatched version/API/source fingerprint is restarted;
• an unrelated process on port 4317 is never stopped;
• malformed or incomplete health identity fails closed;
• launcher readiness still verifies that the new process owns the listener.

Prefer deterministic Python tests plus isolated PowerShell/helper tests where practical. Do not require internet access, a model call, or a live user repository.

---

Constraints to preserve

• zero third-party runtime dependencies;
• no coordination server, daemon authority, database server, or hosted queue;
• Doctor remains deterministic and zero-model by default;
• Deep Review remains explicit, isolated, read-only, capped, and unable to write coordination state;
• Mission Control remains a localhost observer rather than a second coordination authority;
• SessionStart remains read-only and grants no new permission;
• no application-code scan and no transcript-body parsing for Doctor;
• local state remains project-scoped and Git-ignored as currently designed;
• user authority remains above Coordinator messages.

Non-goals

• adding cross-machine synchronization;
• adding an always-running autonomous company loop;
• changing worker ceilings or goal decomposition;
• redesigning Mission Control;
• replacing Markdown/YAML state with a database;
• broad refactoring unrelated to these integrity defects.

---

Definition of done

• PR feat(coordinator): harden Doctor and launch guidance #18 behaviour is preserved and this work is implemented on top of it.
• Marker parsing is strict and semantically consistent across SessionStart, Mission Control, and Doctor.
• Duplicate project IDs cannot overwrite, misroute, or deduplicate findings across roots.
• Mission Control runtime identity is verified before an existing process is reused.
• All new regression cases pass.
• python -m unittest discover -s tests -p "test_*.py" -v passes.
• Python compilation, JavaScript syntax checks, and git diff --check pass.
• Public hygiene, Gitleaks, and existing CI checks pass.
• Documentation and CHANGELOG.md describe only user-visible behaviour changes.
• A clean checkout of the resulting exact tag can install the plugin, trust the hook, start Mission Control, run Doctor, and complete one interrupted/recovered coordinated goal.

Suggested Codex Coordinator execution

Use Codex Coordinator itself for this issue. A sensible maximum of three durable lanes would be:

1. canonical marker parser + cross-root project identity;
2. Mission Control health fingerprint + Windows launcher behaviour;
3. independent regression tests and integration review.

Keep exact write boundaries non-overlapping, reconcile against PR #18 before editing, and return one checked result rather than three unrelated patches.