Files
stack/docs/native-kanban-sot/MISSION-MANIFEST.md
jason.woltje 49e8a54105
All checks were successful
ci/woodpecker/push/publish Pipeline was successful
ci/woodpecker/push/ci Pipeline was successful
docs(#751): Publish native Kanban/SOT canon (#752)
2026-07-14 17:08:09 +00:00

14 KiB
Raw Blame History

Mission Manifest — Mosaic Native Kanban and Canonical Task SOT P0P3

Mission status: CANON INDEPENDENTLY APPROVED; publication in progress under issue #751 Date: 2026-07-14 Human decision owner: Jason Orchestrator/publication owner: web1 control plane (mos-claude; mosaic-100 acting during Claude quota outage) Execution topology: USC web1, partitioned across collision-free GPT coder2/3/4/5 lanes Canonical requirements: ../requirements/native-kanban-sot.md Frozen integration contract: SHARED-CONTRACT.md and contracts/*.v1.ts

1. Mission statement

Extend current mosaicstack/stack main into the sole native control plane for workspace-scoped project, mission, milestone, task, dependency, assignment, lease, approval, evidence, and audit state. First deliver a thin writable Kanban/List vertical slice; then add deterministic mechanical coordination and execute a one-way migration/cutover from jarvis-brain/Vikunja project/task stores.

Success means every user, agent, orchestrator, specialist, and UI sees and mutates the same PostgreSQL aggregate revisions through typed Gateway commands, with no writable fallback and no hidden second authority.

2. Scope boundaries

In scope

  • Current Drizzle/PostgreSQL schema extension and migrations.
  • Workspace tenancy and authorization from the first migration.
  • Projects, missions, milestones, tasks, normalized tags, dependencies, assignments, durable execution/quarantine state, links, immutable artifacts/evidence joins, outage change proposals, events, approvals, leases, checkpoints, and transactional outbox.
  • NestJS Gateway queries and explicit lifecycle commands.
  • MCP/CLI agent surfaces and generated read-only projections.
  • Thin writable Next.js Tasks Kanban/List, task detail, minimal Projects CRUD, filters, dependency readiness, ownership/lease separation, and audit timeline.
  • Non-LLM Mechanical Coordinator eligibility, proposal, approval-policy, lease/fence, heartbeat, retry, expiry, quarantine, and restart recovery.
  • Planning, Enhance, Coder, Review, SecReview, PR-Monitor, and Certifier role/gate representation.
  • One-way shadow importer, reconciliation, write freeze, final delta, cutover, rollback package, and legacy read-only stabilization.
  • Recovery-posture configuration and health-state/fail-closed contract.

Out of scope

  • Greenfield services, Prisma runtime revival, or jarvis-brain flat files as runtime storage.
  • Writable Markdown/JSON/Valkey/browser/provider fallback.
  • Gitea issue/PR replacement or generic bidirectional provider sync.
  • Calendar, email, GLPI cache, CRM, billing, time tracking, personal-brain migration.
  • LLM scheduling or scope interpretation by the Coordinator.
  • Autonomous gate waiver, certification, merge, release, deployment, or issue closure by Coordinator.
  • Merge authority for Certifier.
  • P4 full portfolio/mission designer and P5 fleet-scale policy unless separately released.

3. Fixed invariants

Every deployment MUST preserve all of the following:

  1. PostgreSQL is the sole writable SOT.
  2. Drizzle on current stack main is the only persistence foundation.
  3. Mutations fail closed when DB write-health cannot be proven healthy.
  4. No file, Valkey, browser, queue, provider, or human note becomes a fallback writer.
  5. TASKS.md, mission.json, and every file export are generated, read-only, non-authoritative, and never import sources.
  6. Human outage notes become attributable post-recovery proposals only.
  7. Workspace is the hard tenant; Team is intra-workspace authorization.
  8. Valkey is expendable; PostgreSQL owns state, leases, fencing, audit, and outbox.
  9. Mechanical Coordinator is deterministic/non-LLM and cannot invent scope, waive gates, certify, or merge.
  10. Certifier is the final independent quality gate and has no merge authority.
  11. Mutations use idempotency and optimistic aggregate versions; worker commands also require a current fencing token.
  12. Recovery tier changes only backup/recovery posture, never authority or gate semantics.

4. Configurable recovery posture

Deployments select Lite, Standard, or High-assurance defaults from ../requirements/native-kanban-sot.md and contracts/recovery-posture.v1.ts. Configurable fields are limited to:

  • backup/base-backup cadence;
  • RPO and RTO targets;
  • PITR retention;
  • WAL archive cadence;
  • restore-test frequency;
  • break-glass drill frequency;
  • encrypted off-cluster storage.

High-assurance defaults are fixed reference values: RPO 15 minutes, RTO 4 hours, encrypted off-cluster WAL every 5 minutes with 35-day PITR, daily base backup, monthly restore test, and quarterly break-glass drill.

5. Canonical role map

User
  ↓ objectives, constraints, ratified decisions
Interaction Layer
  ↓ workspace/project context; no scheduling authority
Portfolio Orchestrator
  ↓ approved mission, cross-project priority/capacity
Project Sub-Orchestrator
  ↓ decomposition, DAG, acceptance, release, routing policy, overrides
Gateway
  ↓ authenticated/authorized typed commands
Project/Task Domain Services
  ↓ transactional state + semantic event + outbox
Mechanical Coordinator
  ↓ deterministic eligibility/proposal/lease/fence/retry/quarantine
Specialists
  Planning → Enhance → Coder → Review → conditional SecReview → remediation
  ↓ complete evidence bundle
Certifier
  ↓ final pass/reject/escalate; NO merge authority
Project Sub-Orchestrator / control plane
  ↓ merge authority after all gates
Post-merge validation

Authority table

Role/layer Owns Explicitly cannot do
User Objectives, constraints, Jason-owned decisions Direct DB/file authority bypass
Interaction Conversation and context resolution Schedule, approve, lease, certify
Portfolio Orchestrator Mission approval, cross-project priority/capacity/global holds Implement or self-certify specialist work
Project Sub-Orchestrator Task decomposition/DAG/acceptance, release to ready, routing policy, overrides, remediation, merge go-ahead Bypass required independent gates
Gateway Identity, tenancy, DTO validation, commands, state-machine enforcement Accept file edits or client SQL as mutations
Domain services Transactional business invariants, semantic events/outbox Depend on Valkey/files for committed truth
Mechanical Coordinator Eligibility, dependencies, proposal, approved routing, lease/fence, heartbeat, retry/quarantine Invent/alter scope, waive gates, certify, merge
Specialists Bounded planning/implementation/review artifacts under a task lease Modify another lane's owned files or self-approve
Certifier Final independent evidence/traceability/gate decision Merge, close provider issue, release, waive policy

6. Gate model

Mandatory gates

  1. Requirements/contract freeze before parallel implementation.
  2. P0 schema/authority threat model and tenant isolation review.
  3. Author and reviewer MUST be different principals/sessions.
  4. Functional review validates requirements, endpoint registry, concurrency, and negative paths.
  5. Mandatory SecReview (secrev) for any auth, authorization, tenant, service-token, secret, database schema/migration, data-integrity, import/cutover, audit, lease/fencing, recovery, or destructive-retirement surface.
  6. Review findings enter bounded remediation owned by the implementation lane.
  7. Raising reviewer re-verifies remediation.
  8. Certifier performs the final independent evidence and traceability gate.
  9. Merge authority remains with mos-claude/Project Sub-Orchestrator control plane after gates pass.
  10. Post-merge CI and situational validation must be terminal green before closure.

Gate outcomes

  • PASS: evidence complete; next authority may proceed.
  • REJECT: findings are explicit and route to remediation.
  • ESCALATE: policy/owner decision required; no implicit waiver.

No role can transform a missing gate into a warning by changing status, editing a projection, or writing Valkey.

7. Slice ownership rules

  1. USC web1 is the sole execution environment; coder2/3/4/5 are independent bounded lanes under Mos.
  2. Every slice has one named file-tree owner and an explicit IN/OUT boundary in TASKS.md.
  3. Two active slices MUST NOT edit the same source file, migration file, generated snapshot, lockfile, or API contract.
  4. coder2 exclusively owns packages/db/src/schema.ts, packages/db/drizzle/**, migration journal/meta/tests, then its disjoint recovery-parser/runbook slice. All schema requests serialize through coder2.
  5. Frozen contracts/*.v1.ts are read-only inputs during implementation. Contract changes require Mos approval, a version bump/amendment, and coordinated rebase before work resumes.
  6. coder3 exclusively owns Gateway DTO/controllers/services and the enumerated apps/gateway/src/mcp/** server files. coder4 owns CLI/projection clients and never edits MCP server files. Web consumers use the exact KBN-105 endpoint/DTO freeze.
  7. coder4 executes one lane order: CLI/projection → pure Coordinator → importer → cutover. The pure Coordinator under packages/coord does not load IDs or access DB, Gateway, Valkey, recovery I/O, or web files; coder3 owns the persistence/service adapter.
  8. Migration/import tooling calls Gateway/migration-only approved ports and does not add a second database model.
  9. Each lane commits only its owned files and reports any needed cross-slice change as a contract-change request instead of editing another lane's tree.
  10. Cross-review is mandatory: no lane reviews its own changes. Recommended ring is coder2 ← coder5, coder3 ← coder2, coder4 ← coder3, coder5 ← coder4, followed by independent SecReview where triggered and Certifier final.
  11. Integration-only edits are a separate serialized slice after component lanes are green; no opportunistic merge-conflict resolution may alter semantics.

8. Delivery phases and exit gates

P0 — Canon and authority foundation

  • Publish this canon, frozen schema/ports/health/recovery contracts, threat model, authorization matrix, exact endpoint/DTO registry, concrete current-main field-by-field migration map, and standards amendment.
  • Build hold remains active until independent author≠reviewer re-review returns GO on health proof/failures, approval binding, fencing, tenant relationships, proposals, migration map, slice ordering/API freeze, recovery validation, and vocabulary alignment.
  • Exit: no unresolved second writer or contract blocker, tenant boundary frozen, all seven decisions traceable, and independent re-review GO recorded.

P1 — Thin native MVP

  • Schema/migration, tenant-safe Gateway, CLI/MCP/projection, writable Kanban/List/Projects, dependencies/readiness/audit.
  • Exit: same revision across web/CLI/MCP/projection; cross-workspace tests fail closed; generated files cannot mutate state.

P2 — Mechanical coordination

  • Agent/session registry, deterministic engine, approval queue, PostgreSQL leases/fencing/checkpoints/outbox, retry/quarantine, operations UI.
  • Exit: one lease winner, stale tokens rejected, dependencies/approvals enforced, DB/Valkey fault semantics proven, Certifier gate has no merge authority.

P3 — Shadow migration and cutover

  • Importer, lineage, reconciliation, reviewer UI, write freeze, final delta, Gateway switch, legacy read-only, stabilization and rollback package.
  • Exit: signed reconciliation, zero active legacy writers, scoped Gateway identities, imported backlog cannot dispatch accidentally.

9. Evidence required for mission closure

  • Requirement-to-test/evidence matrix.
  • Schema/migration and N-1 rolling-deploy proof.
  • Cross-workspace API/repository/import/Coordinator negative tests.
  • Health-state and fail-closed fault injection.
  • Valkey-loss/outbox replay and Coordinator restart tests.
  • Concurrent lease and stale fencing tests.
  • Endpoint-registry alignment across web/CLI/MCP/Gateway.
  • Accessible real-Gateway Kanban journeys.
  • Generated projection tamper/no-import proof.
  • One-way migration dry-run/apply/verify and field reconciliation.
  • Author-independent functional review and required SecReview.
  • Certifier final decision and evidence bundle.
  • Merged main SHA, terminal green CI, closed linked task/issue, and post-merge situational validation under orchestrator ownership.

10. Change control

This manifest is derived from the ratified source plan. Any change to SOT authority, workspace tenancy, fixed statuses, Coordinator/Certifier authority, health-state semantics, schema v1, migration direction, or recovery-tier field set is a contract change. Contract changes require Jason/Mos authorization and cannot be inferred by an implementation lane.

No coder lane may start while the build hold is active. KBN-010 must complete before KBN-100; KBN-105 exact endpoint/DTO freeze must complete before any API consumer implementation.