Skip to content

M1 implementation brief: State foundation and estate baseline

Work contract

Field Value
Milestone M1
Status at handoff review requested; Gates A-D complete; M1.5 pilot and M1.6 foundation retrieval pass
Primary gaps G3, G7, G8, G14
Definition items D-01, D-02, D-03, D-04
Depends on M0 verified
Initial mode Design and read-only discovery; no external mutation before approval gates

Objective

Create the persistent state and estate foundation that lets Conductor discover what already exists, compare it with requested work, and let ephemeral agents resume from durable state.

External review decision

M1 is review requested. Gates A-D completed on 2026-07-26. Approved gh operator discovery covers the accepted application boundary; nine Notion databases and 131 candidate Assets are live; the six-member representative group is reviewed; and fresh-client retrieval covers Initiative, concurrent workstreams, Assets, relationships, evidence, and all 103 GitHub repositories. The evaluator correctly returns insufficient-context when no authoritative comparison exists. Producing a real decisive comparison is M4 execution, and unattended GitHub authentication is an M3 runtime decision.

M1 must establish:

  • A physical Notion model for Initiatives, Workstreams, Products, Assets, and Decisions/Events.
  • A reviewed Asset registry distinct from Initiatives.
  • Read-only Conductor access to approved Notion and GitHub state.
  • An approved inventory of authoritative estate sources.
  • A reviewed baseline derived from approved source coverage, with explicit gaps and a representative golden-path application analysis.
  • A reproducible query path for reuse, extend, new, or insufficient-context evidence.

Locked M0 boundaries

Do not reopen these decisions:

  1. Conductor does not write routine Notion or production state.
  2. Executing agents persist state and completion evidence.
  3. Notion is authoritative for Initiative, workstream, Product, Asset, and Decision/Event state.
  4. GitHub is authoritative for source and software delivery evidence.
  5. Assets are enduring systems; Initiatives are work that creates or changes outcomes.
  6. The estate index is derived and cannot override reviewed Asset records.
  7. The Conductor identity allocator mints stable IDs; executing agents persist them.
  8. Decision/Event ownership follows the verified authority model.
  9. Secret values remain authoritative only in Bitwarden; configuration contains names and bindings only.
  10. Read access must be permission-filtered, provenance-aware, and explicit about stale or unavailable sources.

Authoritative references:

Mandatory decision gates

An implementing agent may draft contracts and candidate schemas before these gates. It must not create databases, configure credentials, write Asset records, or change external state until the applicable gate is explicitly approved.

Gate A: Physical Notion model

Decide and obtain approval for:

  • Target Notion workspace and parent page.
  • Database-versus-child-record layout for Workstreams and Decisions/Events.
  • Separate databases for Initiatives, Products, and Assets.
  • Required relations, identifiers, properties, lifecycle states, views, and indexes.
  • Completion/writeback representation.
  • Migration and rollback approach if related databases already exist.

Recommended starting point:

  • Separate Initiatives, Workstreams, Products, Assets, and append-oriented Decisions/Events databases.
  • Relations connect workstreams and events to Initiatives; Products and Assets may link to many Initiatives.

Approval evidence must identify the approved schema version and mutation scope.

Gate B: Asset and reuse model

Decide and obtain approval for:

  • Stable Asset identity and alias handling.
  • Purpose, users, needs, and comparable capability vocabulary.
  • Lifecycle, estate, provenance, privacy, freshness, and relationship fields.
  • Duplicate, fork, replacement, dependency, and supersession relationships.
  • Evidence required for reuse, extend, new, and insufficient-context.
  • Which equivalence or merge decisions always require human review.

Automated extraction may create candidates. It must not silently merge Assets or mark extracted descriptions authoritative.

Gate C: Source and access scope

Obtain explicit scope for:

  • Notion workspaces/databases Conductor may read.
  • GitHub users, organizations, and repositories to enumerate.
  • Workspace pointers and local-only prototype locations to inventory.
  • Deployed hosts/services that may reveal Assets absent from GitHub.
  • Privacy classes and metadata Conductor may index.
  • Bitwarden secret names used for read-only access. Never place values in this brief or repository.

Define behavior for denied, unavailable, stale, partial, and rate-limited sources before enabling reads.

Gate C approves bounded discovery. It does not require Hector to name applications before discovery. Estate completeness is assessed from approved source coverage, exclusions, pagination, privacy filtering, and explicit failure states—not memory.

Gate D: External mutation and baseline import

Before any Notion creation or import, present:

  • Approved schema and source scopes.
  • Dry-run list of proposed database changes.
  • Candidate Asset inventory with provenance.
  • Suspected duplicate/related groups.
  • Proposed golden-path Asset records with comparable capabilities, preferably from the real-estate domain when discovery finds a suitable candidate.
  • Rollback and partial-failure procedure.

Hector must approve the mutation/import plan. Approval of schema design alone is not approval to import records.

Work packages

M1.1 State schema

Deliver:

  • docs/state-model.md with the approved physical Notion model.
  • Field definitions, types, requiredness, relations, lifecycle constraints, and authoritative writers.
  • ID mint/persist flow.
  • Completion/writeback and Decision/Event model.
  • Required Portfolio and review views.
  • Bootstrap/migration plan and rollback.

Do not copy the authority matrix; reference it and specify only physical realization.

M1.2 Asset registry contract

Deliver:

  • docs/asset-registry.md with the approved Asset schema and relationship model.
  • Capability-description guidance that supports meaningful comparison.
  • Provenance, freshness, privacy, and review status.
  • Reuse-decision evidence contract.
  • Candidate-to-reviewed promotion flow.

The registry must describe systems that lack GitHub repositories and systems with multiple repositories or deployments.

M1.3 Read-access contracts

Deliver:

  • docs/read-access-contract.md for Notion, GitHub, and approved supplemental sources.
  • Read-only permission requirements.
  • Secret names and provider bindings.
  • Snapshot version, provenance, freshness, pagination, and rate-limit behavior.
  • Permission filtering and redaction.
  • Unavailable, stale, partial, revoked, and malformed-source behavior.
  • Assurance that read adapters cannot mutate authoritative state.

Implementation may add adapter code and tests only after Gate C and through the repository's normal issue/PR process.

M1.4 Source inventory and dry run

Deliver:

  • docs/source-inventory.md listing approved source scopes and known exclusions.
  • Machine-readable candidate inventory in a path selected during implementation planning.
  • Dry-run report with source coverage, failures, suspected duplicates, and unknowns.
  • Candidate records from the approved source enumeration and a documented golden-path selection.

Local-only Assets require a canonical central reference or an explicit portability gap. A path on one computer is not sufficient estate identity.

M1.5 Reviewed estate baseline

After Gate D, create or update approved Notion records and produce:

  • Reviewed Asset baseline with stable IDs.
  • Verified repository, deployment, and Initiative links where known.
  • Human decisions for duplicates, superseded systems, and material distinctions.
  • Explicit unresolved inventory gaps.
  • Baseline verification timestamp and source coverage report.

The baseline must state its source-defined completeness and unresolved gaps. At least one representative application—or related group—must have comparable purpose, users, needs, capabilities, provenance, freshness, privacy, and relationships.

M1.6 Retrieval verification

Demonstrate that a fresh, read-only Conductor context can:

  • Retrieve an Initiative and its concurrent workstreams.
  • Retrieve related Product, Asset, and Decision/Event records.
  • Find the selected golden-path Asset or related group from a matching request.
  • Cite authoritative sources and freshness.
  • Explain relevant overlap and differences.
  • Return evidence supporting reuse, extend, new, or insufficient-context without silently deciding an unreviewed Asset merge.

This verifies state and retrieval foundations; final plan authorization remains M3/M4.

Required execution sequence

  1. Open or link the M1 tracking issue before external implementation work.
  2. Read the M0 authority and component contracts.
  3. Draft Gate A and Gate B decisions without external mutation.
  4. Obtain Gate A and Gate B approval.
  5. Inventory candidate sources and draft Gate C.
  6. Obtain Gate C approval before using credentials or external reads.
  7. Implement and test read-only adapters where approved.
  8. Run source enumeration and produce the dry-run candidate inventory.
  9. Present Gate D with rollback and privacy evidence.
  10. Obtain Gate D approval before Notion creation/import.
  11. Create the reviewed baseline and resolve candidate groups with human review.
  12. Run retrieval verification from a fresh client context.
  13. Update documentation, roadmap, issue, and evidence links.
  14. Request external M1 review; do not self-mark verified.

Non-goals

  • Do not migrate or align corpus policy; that is M2.
  • Do not implement final plan authorization or compact execution packs; that is M3.
  • Do not implement scheduled learning; that is M5.
  • Do not build multi-organization onboarding; that is M6.
  • Do not make Conductor a Notion writer.
  • Do not make GitHub Issues mandatory.
  • Do not infer Asset equivalence from repository name, stack, or embeddings alone.
  • Do not import unreviewed AI-generated descriptions as authoritative.
  • Do not store secret values outside Bitwarden.

Acceptance conditions

M1 may be externally verified only when:

  1. The physical Notion state schema is approved, versioned, and documented.
  2. Initiatives, Workstreams, Products, Assets, and Decisions/Events have stable IDs and validated relations.
  3. Executing-agent writeback and completion records are testable without Conductor writes.
  4. Notion and GitHub reads use an explicitly approved authentication mode, are permission-filtered, provenance-aware, and non-mutating; unattended credential hardening belongs to the runtime milestone.
  5. Source inventory identifies approved scope, exclusions, failures, and stale/partial results.
  6. Asset records separate reviewed facts from extracted candidates.
  7. Every reviewed Asset has purpose, users/needs, capabilities, lifecycle, provenance, freshness, privacy, and relationships as applicable.
  8. Approved sources are exhaustively enumerated or explicitly partial, and at least one representative application or related group is analyzed with comparable, evidence-backed fields.
  9. Duplicate, superseded, and related-Asset decisions have human evidence.
  10. A fresh client can retrieve Initiative state and the relevant estate without local project files.
  11. Reuse evidence safely returns one of reuse, extend, new, or insufficient-context with citations and freshness; M1 may prove the fail-closed result, while M4 proves a decisive real execution.
  12. Missing, stale, denied, or partial sources fail explicitly rather than appearing complete.
  13. No unreviewed extraction is authoritative and no derived index overrides Notion/GitHub.
  14. Required tests, docs build, diff checks, and rollback rehearsal pass.

Required verification evidence

The implementation handoff must include:

  • Approved Gate A-D decisions and their evidence.
  • Schema version and database identifiers without credentials.
  • Read-only permission proof and explicit authentication mode for each source path.
  • Source coverage and dry-run reports.
  • Asset counts by lifecycle, privacy class, and source.
  • Representative golden-path Asset comparison evidence, preferably real estate when a suitable candidate is discovered.
  • Duplicate/supersession review decisions.
  • Fresh-client retrieval transcript or automated test.
  • Partial/stale/denied-source test results.
  • Rollback or recovery test result.
  • GitHub issue/PR/check links.
  • Documentation build and diff-check results.

Stop conditions

Stop and request a decision when:

  • Any Gate A-D input is missing or unapproved.
  • Existing Notion structures conflict with the proposed schema.
  • Read access requires broader permissions than approved.
  • A source contains client/private data without a privacy classification.
  • A candidate merge or supersession is not obvious and human-reviewed.
  • A local-only Asset lacks a portable canonical reference.
  • External mutation would occur without a rollback path.
  • Implementation would require reopening an M0 authority decision.

Final handoff

Report:

  • Work packages completed and files changed.
  • Gates approved, blocked, or pending.
  • External systems read or changed.
  • Baseline coverage and known gaps.
  • Acceptance matrix with exact evidence.
  • Validation results.
  • M1 status as review requested or the named blocker.

Do not self-mark M1 verified.