Skip to content

M3 implementation brief: Authorization vertical slice

Work contract

Field Value
Milestone M3
Status verified
Primary gaps G2, G4, G11, G12
Definition items D-04 runtime mode, D-05, D-06
Depends on M0, M1, and M2 verified
Mutation boundary Conductor emits control-plane review and authorization artifacts; executing agents own project-state and production writes

Objective

Prove one end-to-end supervisory conversation in which a requesting agent prepares a version-bound plan, resolves review findings, receives a compact execution authorization, and is forced to reauthorize after material change.

M3 proves the control plane. It does not execute the real-estate golden path, perform broad candidate triage, or make Conductor a Notion/GitHub/production writer.

Locked inputs

  • Four MCP operations: prepare, converse, authorize, and feedback.
  • Proposed plans, review artifacts, and authorization records are distinct.
  • authorized means Conductor-authorized, never human-approved.
  • One authorization covers one Initiative, workstream, stage, role, exact plan digest, corpus revision, context revision, scope, and conditions.
  • Material plan, context, target, role, stage, or corpus changes invalidate the authorization.
  • Deterministic validation and supervisory judgment are both visible.
  • Human escalation is reserved for authority exceptions and unresolved organization decisions.
  • Executing agents apply authorized changes and persist project-state evidence.
  • Operator-mediated gh remains the GitHub read mode unless a separate unattended runtime decision is approved.

Deliverables

M3.1 Plan bundle

  • Versioned plan-bundle schema.
  • Initiative/workstream/stage/role and exact-target bindings.
  • Proposed operations, expected artifacts, evidence, rollback, assumptions, open questions, and pattern choice.
  • Stable canonical serialization and plan digest.

M3.2 Preparation

  • prepare gathers approved state, estate, corpus, and source envelopes.
  • Source availability, freshness, truncation, and permission gaps remain explicit.
  • Compact initial pack includes selection reasons and expansion handles.
  • Preparation cannot authorize execution.

M3.3 Conversational review

  • converse records questions, findings, refusals, revision requests, escalations, and resolved decisions.
  • Review distinguishes deterministic failures from judgment-led concerns.
  • Review artifacts cite the exact plan and context versions.

M3.4 Authorization

  • authorize accepts only a validated, reviewed, exact plan.
  • Authorization envelope is immutable, compact, signed or integrity-bound, and independently verifiable.
  • Status is one of not-reviewed, changes-requested, authorized, or refused.
  • Invalidation rules reject stale or materially changed execution.
  • Authorization IDs come from the Conductor identity allocator.

M3.5 Feedback

  • feedback accepts execution outcome and evidence against an authorization.
  • Feedback never mutates binding corpus automatically.
  • Project-state writeback remains the executing agent's responsibility.

M3.6 Evaluation and audit

  • Positive end-to-end fixture through authorization and feedback.
  • Negative fixtures for digest changes, stale context, role/stage/target drift, missing evidence, unauthorized expansion, replay, and false human-approval representation.
  • Immutable authorization and review-event audit records.

Entry conditions

  1. M1 receives independent verification of its state/read foundation.
  2. M3 decision package is approved.
  3. Implementation issues define bounded schema, preparation, review, authorization, and feedback work.

All entry conditions are satisfied. Tracking issue: #15, with bounded work packages #16 through #20.

Implementation evidence

  • Versioned schemas cover proposed plans, prepared contexts, review artifacts, authorization envelopes, and feedback.
  • The public MCP surface exposes prepare, converse, authorize, and feedback; none performs project-state or production mutation.
  • Compact-context expansion generates a different deterministic context revision. Review and authorization reject it until a newly digested plan binds that revision.
  • Authorization envelopes are allocator-identified, integrity-bound, immutable in the audit store, expiring, and one-shot.
  • The positive lifecycle and adversarial digest, context, target, stage, role, evidence, expansion, replay, and false-human-approval cases are executable in service/tests/test_m3_control_plane.py.
  • Local verification: 16 focused tests and 114 complete service tests pass; strict documentation build and diff checks pass.

Independent verification is recorded in verification.md. The reviewer reproduced 28 focused positive/adversarial checks, all 114 service tests, strict documentation, and the diff check at c40c0ea.

Exit conditions

  1. A fresh requesting agent can prepare a plan from approved remote context.
  2. Review findings produce a revised, separately identified plan.
  3. An exact reviewed plan receives a verifiable authorization envelope.
  4. Any material mutation invalidates that authorization.
  5. Expansion requires a new plan and authorization.
  6. Feedback is bound to the authorization and cannot promote corpus policy.
  7. Conductor performs no routine project-state or production mutation.
  8. Independent verification reproduces positive and adversarial fixtures.

Non-goals

  • Real-estate execution and decisive reuse/extend/new outcome (M4).
  • Learning candidate promotion (M5).
  • Second-organization portability (M6).
  • Unattended GitHub credentials unless separately approved as necessary.