#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

This summary and the proposed first increment below.
Permission bundles and publication/lifecycle rules.
Mediated operations, evidence and implementation gates.
The exact declarative records, command events, and runtime/control/artifact shapes, 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:

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

Actual mediation, narrow mounts/egress, credential separation and stopping.
Authentic, durable publication and safe recovery/idempotency.
Conversation/context/output privacy and current permission checks.
Reset/prune protection for newly required state/evidence. Current scripts have not gained the proposed protections.
Reconciliation with #50's canonical definitions and stable per-execution inputs; no credential refresh experiment was performed and OAuth gate 7 is still open.
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:

Inspect one project with two workspaces and an agent registered only in the first.
See the exact authorized first-workspace view and refusal for the second.
Try ambiguous IDs, missing parents, stale revisions and an overbroad grant; each must fail clearly rather than select a default.
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.

9.7 KiB Raw Blame History