stack/docs/plans/foundation-v1-candidate/REVIEW.md

# #53 phase 2: owner review

**Owner: Jason. Status: phase-2 planning baseline accepted, 2026-09-06.**

This is a design contract, not a claim that Mosaic now enforces it. The existing
agent launch remains a limited legacy checkpoint. Q1-Q28 establish the behavior
requirements; this package proposes the exact records and operating rules.

## What you are approving

- One reusable agent identity, explicitly registered into projects/workspaces.
  Each workspace has one project. Membership, dependencies and conversation
  visibility remain separate.
- Resume by default; automatic announced first conversation only on genuine first
  use. Fresh excludes old chat and rebuilds authorized work context. Damaged history
  causes an error. Existing legacy history needs explicit reviewed adoption.
- Standard nonhierarchical permission bundles, narrowed by registrations, mission,
  task and execution limits. Administrative/control powers are separate grants.
  No task combines other assignments' permissions or accepts its own delivery.
- **Q28 A:** a Mosaic-controlled terminal backed by Pi. The broker, not terminal
  shortcuts, engine text or client state, owns admission, control and routing.
  One controller; explicitly authorized observers and transfer.
- Invocation-level command evidence with real enforced limits. No promise to trace
  every internal file/network operation. Stopping, recovery, privacy and recording
  remain mandatory even when a command reports exit zero.
- Append-only evidence, serialized publication, safe refusal and no blind replay.
  Stable launch inputs; non-blocking shared-configuration notices recommend Fresh.

You are **not** approving implementation, migration, live policy changes, new
credentials, a release, mapping, independent-review acceptance, commit/push or
issue closure. Those retain their separate gates. This goal is complete only
when you accept the phase-2 contract, not when its author says the checks pass.

## Review order

1. This summary and the proposed first increment below.
2. [Permission bundles and publication/lifecycle rules](README.md).
3. [Mediated operations, evidence and implementation gates](RUNTIME.md).
4. The exact [declarative records](records.schema.json),
   [command events](command-events.schema.json), and
   [runtime/control/artifact shapes](runtime.schema.json), as needed.

The schema types are closed. Runtime schema includes 16 runtime/artifact kinds,
28 control operations, prompt/stop/dialog input and common responses. The separate
command request completes the 29-operation catalog. Source registry references
remain dynamic identifiers; these files are not a new live registry.

## Checks and their limits

Run the author checks with:

```bash
python3 docs/plans/foundation-v1-candidate/check.py
```

- 38 command shape cases, 38 declarative record cases and 16 path cases.
- Seven restricted-domain hash vectors, also checked against the projection type.
- 155 runtime/control/artifact cases, including valid conditional branches and
  refusal shapes. Zero controller generation is invalid; actual stale-generation
  refusal is a state check, not something JSON Schema alone proves.
- 35 synthetic reference, permission, path, acceptance and claim/recovery model
  cases. These execute proposed rules against fixture assumptions, not live facts.
- Ten deliberately shape-valid forgeries remain shape-valid. A trusted runtime
  must reject their false authority, bindings, hashes or assertions.

The checker also compares shared definitions and checks that the operation catalog
has request coverage. Fixtures are not an authenticated run, a coherent deployed
registry or a sandbox test. The reference model assumes its input observations;
it cannot authenticate a producer or observe a real process. No independent agent
has approved this package. Full JCS implementation/Unicode vectors and live
failure-injection/security tests belong to the separately chartered implementation.

## D1-D16 reconciliation

“Candidate” below means a review proposal covers the question, not that code is
implemented or the owner has approved every field.

| Design question | Candidate location and remaining proof gate |
|---|---|
| D1: scope/hierarchy | Record schemas and README reference/lifecycle rules. Actual parent, mission-completion and acyclicity checks required. |
| D2: Fresh recovery content | Context classifications, launch inputs and RUNTIME recovery projection. Actual publisher/loader provenance and no-old-chat tests required. |
| D3: delegation/visibility/revocation | Permission bundles, delegation basis and current-authority rules. Actual identity, ceiling, propagation and affected-work stopping tests required. |
| D4: genuine first use/Resume | Explicit initial/resume/fresh records, snapshot/leaf binding and historical markers. Damaged-state and initial-bootstrap tests required. |
| D5: Abandon/prerequisites | Typed work selection and assignment changes; assignment-only Abandon and independent reviewer rules. Interruption/authorization tests required. |
| D6: storage/retirement/adoption | README storage and RUNTIME retention/reopening/adoption rollback rules. Real protection, mapping and recovery tests required. |
| D7: conflicts/connections/replacement | Claim, connection, control and termination shapes plus synthetic traces. Actual single-controller, concurrency and full-cohort stopping proof required. |
| D8: uncertainty recovery | README crash traces, RUNTIME evidence, synthetic claim model. Files/processes/journal failure injection required. |
| D9: audit failure/integrity | Command events, classified artifacts, publisher ordering and outage rules. Trusted durable writer tests required. |
| D10: shared config/#50 | README compatibility and RUNTIME stable snapshots. Current #50 per-seat materialization and OAuth gate 7 remain external constraints. |
| D11: taskless work/command coverage | Closed command/control shapes and Q27 rule. No unassigned file changes; actual command isolation/recording required. |
| D12: adapter enforcement | Q28 A architecture and capability matrix. Pinned docs are evidence of documented APIs, not complete mediation. |
| D13: context/privacy | Context-source classifications, launch inputs, artifact visibility and routing. Actual loader/output/recipient tests required. |
| D14: shared interface | Q28 A plus complete operation/request catalog and common response codes. CLI presentation cannot create extra authority. |
| D15: plan changes/autonomy/acceptance | README lifecycle/reference rules, request binding, decision/delegation basis and synthetic acceptance cases. Current-intent, non-author reviewer and evidence checks must be enforced. |
| D16: fingerprints/notices | Projection, vectors and RUNTIME event-triggered comparison. No silent reload or continuous-state claim; real delivery/adapter checks required. |

The requirement source remains R1-R34 in the foundation plan. Independent mapping
and gap review may find defects in this candidate; changes must preserve owner
rulings or return for a new owner decision.

## Technical gates that acceptance does not waive

1. Actual mediation, narrow mounts/egress, credential separation and stopping.
2. Authentic, durable publication and safe recovery/idempotency.
3. Conversation/context/output privacy and current permission checks.
4. Reset/prune protection for newly required state/evidence. Current scripts have
   not gained the proposed protections.
5. Reconciliation with #50's canonical definitions and stable per-execution inputs;
   no credential refresh experiment was performed and OAuth gate 7 is still open.
6. **Legacy bypass closure:** current broad-mount/native launch paths cannot remain
   an ungoverned route into protected foundation state. Before activating that state,
   refuse those paths or establish a separately approved isolation boundary. Do not
   assume a new broker makes the old adapter safe.

None requires changing a settled owner behavior today. If implementation research
cannot meet a gate with the selected adapter, stop and report instead of weakening
it or silently upgrading the pinned engine.

## Recommended first user-testable increment

**A read-only foundation scope/permission inspector using a synthetic bundle.**

Example future spelling: `mosaic foundation inspect <bundle.json>`. The later
charter settles the executable/wrapper. It validates a coherent candidate graph,
resolves exact project/workspace membership and previews the permission intersection.
Output must say **preview: no live registrations or permission grants**.

Owner test:

1. Inspect one project with two workspaces and an agent registered only in the first.
2. See the exact authorized first-workspace view and refusal for the second.
3. Try ambiguous IDs, missing parents, stale revisions and an overbroad grant;
   each must fail clearly rather than select a default.
4. Confirm no data-root state, credentials, sessions or running agents changed.

This refines the earlier metadata-registration recommendation: live persistence
also requires publisher, retention and legacy-bypass protections. A read-only
inspector supplies a small usable checkpoint without pretending those already
exist. It requires a coherent semantic fixture bundle, not simply combining the
independent shape fixtures in this directory.

Only after phase-2 acceptance, separately approved mapping and independent gap
review should that increment receive an implementation charter. Owner testing
then precedes any dependent increment.

## Owner verdict

Jason explicitly answered **"accept phase 2"** after the plain-language
clarification that this accepts the plan, not a security certification or
implementation mandate. Receipt recorded at 2026-09-06 06:52 UTC.

Goal issue-53-phase2 is satisfied. Technical mapping, independent review and
implementation remain separately authorized phases; none starts automatically.