Scope: v0.1 first 30 days, with future adapter context for identity, task contracts, settlement, and reputation.
+Scope: bounded v0.1 delivery, with future adapter context for identity, task contracts, settlement, and reputation.
@@ -26,7 +26,7 @@ evidence packet, every valid human decision an immutable Review and reviewer
contribution, and every accepted task an immutable FinalAcceptance before the
submitter contribution and conditional compensation.
-The first 30 days are focused on proving the internal lifecycle:
+v0.1 is focused on proving the internal lifecycle:
```text
Project Guide -> Task Queue -> Submission Packet -> Checks -> Review
@@ -77,7 +77,10 @@ The context diagram shows Workstream as one system inside the broader Flow ecosy
## C2: v0.1 Container View
-The container view shows the first 30-day implementation. It is intentionally small: React + Vite for the planned internal operations UI, FastAPI for the backend, Postgres for records, a storage interface for artifacts, and an async checker/job boundary.
+The container view shows the bounded v0.1 implementation. It is intentionally
+small: React + Vite for the planned internal operations UI, FastAPI for the
+backend, Postgres for records, a storage interface for artifacts, and an async
+checker/job boundary.
@@ -175,7 +178,7 @@ Future ERC-8004, ERC-8183, x402, OmniClaw, and USDC integrations do not replace
## Scope Boundary
-### Current v0.1 / First 30 Days
+### Current v0.1 Boundary
- project guide and versioned policy context
- task queue and task records
diff --git a/docs/architecture_brief/workstream_architecture_brief.pdf b/docs/architecture_brief/workstream_architecture_brief.pdf
index 26811596f..4bab3cb16 100644
Binary files a/docs/architecture_brief/workstream_architecture_brief.pdf and b/docs/architecture_brief/workstream_architecture_brief.pdf differ
diff --git a/docs/architecture_system_architecture.md b/docs/architecture_system_architecture.md
index da2d4cf80..f1501853e 100644
--- a/docs/architecture_system_architecture.md
+++ b/docs/architecture_system_architecture.md
@@ -11,7 +11,11 @@ the REV-13 joint release complete. `docs/spec_review_lifecycle.md` is normative.
The architecture stays modular enough to support different project types without becoming abstract to the point that no project can use it.
-The visual architecture pack lives in [Architecture Diagrams](diagrams/README.md). It separates the 30-day v0.1 implementation from later adapter boundaries such as ERC-8004 agent identity and reputation, ERC-8183 task contract and escrow, x402 payment requests, OmniClaw settlement orchestration, and USDC settlement.
+The visual architecture pack lives in
+[Architecture Diagrams](diagrams/README.md). It separates the bounded v0.1
+implementation from later adapter boundaries such as ERC-8004 agent identity
+and reputation, ERC-8183 task contract and escrow, x402 payment requests,
+OmniClaw settlement orchestration, and USDC settlement.
## High-Level Components
diff --git a/docs/checker_trial_failure_catalog.md b/docs/checker_trial_failure_catalog.md
index dd17bb782..8d1013817 100644
--- a/docs/checker_trial_failure_catalog.md
+++ b/docs/checker_trial_failure_catalog.md
@@ -1,10 +1,18 @@
# Checker Trial Failure Catalog
+> Historical validation record. It preserves early checker evidence and does
+> not define current sequencing or capability status.
+
## Purpose
This catalog records the Chunk 10 checker trial outcomes. It is the audit note for the first real sample submissions run through the Week 2 checker framework.
-The trial does not add a lifecycle state, a review decision, or a frontend surface. It proves the current backend contracts for clean submissions, worker-fixable checker failures, internal task setup failures, and trusted checker retry.
+The trial does not add a lifecycle state, a review decision, or a frontend
+surface. It records early checker-trial evidence for clean submissions,
+contributor-fixable checker failures, internal task setup failures, and trusted
+checker retry. It does not establish current backend behavior; use
+[Current v0.1 Status](roadmap_status.md) and merged code and tests for current
+capabilities.
## Trial Results
diff --git a/docs/diagrams/README.md b/docs/diagrams/README.md
index a58299132..f84a67fdb 100644
--- a/docs/diagrams/README.md
+++ b/docs/diagrams/README.md
@@ -2,7 +2,7 @@
This diagram pack explains Workstream at two levels:
-- the 30-day v0.1 implementation that is being built now
+- the bounded v0.1 implementation that is being built now
- the broader Workstream ecosystem that can connect later to external origins, agent identity, task contracts, settlement rails, and portable reputation
The architecture diagrams use C4-PlantUML source files so they render with real C4 system, container, component, boundary, and external-system boxes. The task lifecycle sequence remains Mermaid because GitHub renders it directly and the sequence is easier to read in that format.
@@ -41,4 +41,8 @@ The rendered SVGs are written to `docs/diagrams/rendered/` and are committed so
## Reading Order
-Start with the [System Context](workstream_context.md) to explain what Workstream is and what it does not own. Then use the [v0.1 Container View](workstream_v01_container.md) to show what is actually being implemented in the first 30 days. Use the backend component and lifecycle diagrams when the discussion moves from product architecture into implementation design.
+Start with the [System Context](workstream_context.md) to explain what
+Workstream is and what it does not own. Then use the
+[v0.1 Container View](workstream_v01_container.md) to show the bounded v0.1
+implementation. Use the backend component and lifecycle diagrams when the
+discussion moves from product architecture into implementation design.
diff --git a/docs/diagrams/backend_v01_components.md b/docs/diagrams/backend_v01_components.md
index 1a9b6e7d6..d9beed7b3 100644
--- a/docs/diagrams/backend_v01_components.md
+++ b/docs/diagrams/backend_v01_components.md
@@ -22,7 +22,8 @@ Source: [backend_v01_components.puml](backend_v01_components.puml)
## Current Module Priority
-The first 30 days move through the loop in this order:
+The v0.1 backend follows the Workstream product lifecycle in this dependency
+order:
```text
Projects and guides
diff --git a/docs/diagrams/workstream_v01_container.md b/docs/diagrams/workstream_v01_container.md
index fdcaed459..26b66ee54 100644
--- a/docs/diagrams/workstream_v01_container.md
+++ b/docs/diagrams/workstream_v01_container.md
@@ -1,6 +1,7 @@
# Workstream v0.1 Container View
-This is the 30-day implementation architecture. It shows the deployable containers and internal runtime boundaries for the current build.
+This is the v0.1 implementation architecture. It shows the deployable
+containers and internal runtime boundaries for the current build.
Future external origins, ERC-8004, ERC-8183, x402, OmniClaw, and USDC settlement are not active v0.1 dependencies. They remain later adapters behind the same records and interfaces.
diff --git a/docs/historical_planning.md b/docs/historical_planning.md
new file mode 100644
index 000000000..458c05055
--- /dev/null
+++ b/docs/historical_planning.md
@@ -0,0 +1,31 @@
+# Historical Planning Index
+
+These documents record how Workstream's early implementation was planned and
+validated. They are preserved for traceability. They do not define current
+priority, implementation status, contribution permission, or a delivery
+schedule.
+
+For current work, start with [CONTRIBUTING.md](../CONTRIBUTING.md) and follow its
+engineering loop. Then use [Current v0.1 Status](roadmap_status.md), the code
+and tests on `main`, accepted ADRs, and the canonical subsystem specifications.
+
+## Superseded Calendar Plans
+
+- [Original 30-Day Master Plan](roadmap_30_day_master_plan.md)
+- [Original Day-by-Day Execution Plan](roadmap_day_by_day_execution_plan.md)
+- [Original Week 1 Backend Plan](roadmap_week1_backend_plan.md)
+- [Original Week 2 Checker Framework Specification](spec_week2_checker_framework.md)
+- [Original Implementation Backlog](roadmap_implementation_backlog.md)
+
+## Early Implementation Records
+
+- [Submission Packet Foundation](spec_chunk_5_submission_packet_foundation.md)
+- [Checker Contract And Records](spec_chunk_6_checker_contract_records.md)
+- [Checker Runner And Registry](spec_chunk_7_checker_runner_registry.md)
+- [Submission Artifact And Policy Checkers](spec_chunk_8_submission_artifact_policy_checkers.md)
+- [Pre-Review Gate](spec_chunk_9_pre_review_gate.md)
+- [Checker Trial](spec_chunk_10_checker_trial.md)
+- [Checker Trial Failure Catalog](checker_trial_failure_catalog.md)
+
+Later canonical specifications and initiative records supersede these files
+where they describe the same behavior.
diff --git a/docs/operations_reviewer_workflow.md b/docs/operations_reviewer_workflow.md
index 10259f50d..bde361c6e 100644
--- a/docs/operations_reviewer_workflow.md
+++ b/docs/operations_reviewer_workflow.md
@@ -214,7 +214,7 @@ create adjudication state, overturn a Review, or mutate immutable history.
## Non-Mutating Quality Sampling
-During the first 30 days, audit at least:
+For v0.1 operations, audit at least:
- 25 percent of accepted submissions
- 25 percent of rejected submissions
diff --git a/docs/product_brief.md b/docs/product_brief.md
index e26f9c571..5eb1ff3f7 100644
--- a/docs/product_brief.md
+++ b/docs/product_brief.md
@@ -114,7 +114,10 @@ The only v0.1 intake paths are:
- manual task creation in the app
- import from a controlled markdown or CSV template
-External source adapters, origin onboarding, webhook drop notifications, automated routing, owner-agent execution workspace, and on-chain settlement are later work. This keeps the first 30 days focused on proving the lifecycle, not integrating every source.
+External source adapters, origin onboarding, webhook drop notifications,
+automated routing, owner-agent execution workspace, and on-chain settlement are
+later work. This keeps v0.1 focused on proving the internal lifecycle instead
+of integrating every possible source or settlement rail.
The first version excludes:
@@ -144,7 +147,7 @@ Avoid broad gig marketplace positioning until the quality engine is proven.
## Success Metrics
-By day 30:
+The v0.1 pilot is successful when it demonstrates:
- 3 project templates configured
- 20 tasks entered
diff --git a/docs/roadmap_30_day_master_plan.md b/docs/roadmap_30_day_master_plan.md
index 1e8bfeebd..8948f9b9e 100644
--- a/docs/roadmap_30_day_master_plan.md
+++ b/docs/roadmap_30_day_master_plan.md
@@ -1,5 +1,9 @@
# 30-Day Master Plan
+> Historical planning record. This calendar no longer controls current work or
+> status. Use [Current v0.1 Status](roadmap_status.md) and the
+> [Historical Planning Index](historical_planning.md).
+
## Review Lifecycle Status
The schedule is planning guidance, not a claim that review/revision routes are
diff --git a/docs/roadmap_day_by_day_execution_plan.md b/docs/roadmap_day_by_day_execution_plan.md
index 2cd52e78d..be3083b94 100644
--- a/docs/roadmap_day_by_day_execution_plan.md
+++ b/docs/roadmap_day_by_day_execution_plan.md
@@ -1,5 +1,9 @@
# Day-by-Day Execution Plan
+> Historical planning record. This calendar no longer controls current work or
+> status. Use [Current v0.1 Status](roadmap_status.md) and the
+> [Historical Planning Index](historical_planning.md).
+
## Review Lifecycle Status
The calendar is sequencing guidance, not implementation status. Review and
diff --git a/docs/roadmap_implementation_backlog.md b/docs/roadmap_implementation_backlog.md
index 270e729ab..f8c0f0141 100644
--- a/docs/roadmap_implementation_backlog.md
+++ b/docs/roadmap_implementation_backlog.md
@@ -1,5 +1,9 @@
# Implementation Backlog
+> Historical planning record. This backlog no longer controls current priority
+> or status. Use [Current v0.1 Status](roadmap_status.md) and the
+> [Historical Planning Index](historical_planning.md).
+
## Review Lifecycle Status
Review/revision entries describe planned, unavailable v0.1 work. They become
diff --git a/docs/roadmap_status.md b/docs/roadmap_status.md
index 1d94e1ced..715c4834a 100644
--- a/docs/roadmap_status.md
+++ b/docs/roadmap_status.md
@@ -1,177 +1,127 @@
-# Workstream Roadmap Status
-
-Current phase: WS-AUTH-001 authorization foundation before further lifecycle
-expansion.
-
-## Completed
-
-- Root README.
-- Product principles and product brief.
-- First user flows.
-- 30-day master plan.
-- Day-by-day execution plan.
-- Implementation backlog.
-- Pilot plan.
-- System architecture.
-- Data model.
-- Lifecycle state machine.
-- Checker framework.
-- Operator workflow.
-- Queue policy.
-- Reviewer workflow.
-- Revision replay.
-- Roles and permissions.
-- Compensation and reputation.
-- Workspace and packet convention.
-- Risk register.
-- Templates for guides, tasks, submissions, reviews, checkers, revision replay, and prior feedback.
-- Decision records.
-- Independent review passes.
-- Review closure record.
-- June 3 architecture proposal preserved and reconciled.
-- Architecture lockdown note.
-- Week 1 backend chunk plan.
-- Chunk 1 backend scaffold.
-- Chunk 2 external Flow auth actor boundary.
-- Chunk 3 project guide foundation with checker, review, and revision policy
- context; compensation is superseded by the independent WS-CON contract.
-- Chunk 4 task queue, contributor/reviewer profiles, assignment, claim, start, and task audit events.
-- Chunk 5 submission packet foundation with evidence items, versioning, server-stamped locked context, and submission finalization.
-- Backend API contract drill through `Project -> Guide -> Task -> Screening -> Ready -> Claim -> Start -> Submit -> automatic pre-review gate`.
-- Week 2 checker framework scope specification.
-- Chunk 6 checker contract and records specification.
-- Chunk 7 checker runner, registry, structural checkers, durable checker records, and API tests.
-- Chunk 8 evidence, policy, forbidden-file, confidentiality, and generated-artifact checkers.
-- Chunk 9 automatic pre-review gate with pre-submit intake blocking, internal `task_setup_blocked`, trusted checker retry, and contributor redaction.
-- Chunk 10 checker trial with the expanded real API sample matrix, failure catalog, false-positive notes, missing-checker notes, and internal verifier evidence.
-- Week 2 real HTTP API drill through Flow-token auth, project/guide/task/submission lifecycle, pre-submit checks, automatic checker runs, `pre_submission_checker_failed` intake failures, contributor redaction, internal `task_setup_blocked`, and trusted checker retry.
-- Chunk 11 actor identity/profile registry for verified Flow actors.
-- Chunk 12 project setup-run and project policy visibility APIs for setup runs, sufficiency reports, submission artifact policies, effective policy, and compiled project pre-submit checker policy.
-- Chunk 13 task work-context, contributor submission-requirements, and operator-only locked-context APIs.
-- Chunk 14 submission finalization, system actor pre-review gate audit semantics, scoped operator visibility, and HTTP-visible Terminal Benchmark proof.
-- Chunk 15 agent-derivation hardening after the accepted no-DB Terminal Benchmark drill exposed a required/forbidden self-conflict.
-- Chunk 16 Terminal Benchmark live API drill with privacy-scrubbed evidence and
- professional PDF report proving the current lifecycle through HTTP-visible
- APIs without database inspection.
-- WS-POL-002 post-submit checker foundation planning, including project-scoped
- `PostSubmitCheckerPolicy` setup, trusted compiler boundaries, deterministic
- runtime separation, and implementation chunk contracts.
-- WS-AUTH-001 planning and post-merge memory through PRs #91 and #92, including
- the adopted external-auth/local-authorization boundary and 16 bounded chunks.
-
-## Current Priority
-
-- `WS-AUTH-001-01` adopts ADR 0012, canonical `/api/v1` authorization
- documentation, operational ownership, and deterministic stale-doc gates.
-- Token roles and typed workflow profiles are not the target product authority;
- later chunks introduce canonical actors, links, grants, permissions,
- revocation, and authority evidence before resource-family cutover.
-- WS-POL-002-03 is handled separately by PR #90. No WS-POL-002-04 or human
- review implementation starts automatically while authorization has priority.
-
-## Review Tracks Closed
-
-- Product strategy.
-- Architecture.
-- Systems architecture.
-- Operations and review workflow.
-- Process-pattern baseline.
-- Adversarial quality.
-- Chunk 9 pre-review gate internal verifier pass.
-- Chunk 10 checker trial internal verifier pass.
-
-## Preserved For Later Review Work
-
-- Review queue scope starts only after the required authorization foundation;
- it will consume `review_pending` tasks that already passed internal checkers.
-- Reviewer access must be object-level and tied to assigned review work; broad reviewer checker-run access is still intentionally deferred.
-- Week 3 must keep review decisions canonical: `accept`, `needs_revision`, and `reject`.
-- `needs_revision` from human review must carry `outcome_source = human_review` and a review decision id; checker-caused `needs_revision` keeps `outcome_source = auto_checker`.
-- Review findings, revision replay, and reviewer-quality metrics remain later
- backend contracts after authorization proof.
-- `WS-POL-001-15` hardened the agent-derived submission artifact policy
- contract after the accepted no-DB Terminal Benchmark drill exposed a
- required/forbidden self-conflict; the drill now passes after hardening.
-- `WS-POL-001-16` completed a human-visible Terminal Benchmark live API drill
- without database inspection as lifecycle proof and merged through PR #84.
-- `WS-POL-002` planning and chunks 01/02 are merged. Chunk 03 is handled in PR
- #90; chunk 04 remains inactive while authorization has priority.
-
-## Pending Before Pilot
-
-- Create the first pilot project guide from the template.
-- Create the first 5 pilot task records.
-- Confirm who owns product, engineering, review, operations, and compensation
- fulfillment reconciliation during the first build cycle.
-- Confirm the first v0.1 project guide uses the locked guide fields, task contract fields, evidence IDs, and contribution record flow.
-
-## Backend API Contract Drill
-
-Run from the backend directory against local Postgres:
-
-```bash
-WORKSTREAM_DATABASE_URL=
.venv/bin/python scripts/api_contract_e2e.py
+# Current Workstream v0.1 Status
+
+This is the capability ledger for current v0.1 development. It records what is
+implemented on `main`, what is being integrated, and what remains before the
+v0.1 lifecycle is proven. It intentionally contains no delivery calendar.
+
+Implementation claims must be supported by code, migrations, tests, and merged
+history. A plan, contract, draft pull request, or historical specification is
+not evidence that behavior is live.
+
+## v0.1 Release Boundary
+
+The target remains:
+
+```text
+Project Guide
+-> Task
+-> Submission Packet
+-> Automated Checks
+-> Human Review
+-> Revision when required
+-> Contribution Records
+-> Conditional Compensation Award / Fulfillment
+-> Contribution Evidence For Future Reputation Projection
```
-The script runs migrations forward and exercises project policy visibility plus task context APIs across the following flow:
-
-`Project -> Guide -> Task -> Screening -> Ready -> Work context -> Submission requirements -> Locked context -> Claim -> Start -> Submit -> automatic pre-review gate`
-
-## Week 2 Real API Drill
-
-Run from the backend directory against local Postgres:
-
-```bash
-WORKSTREAM_DATABASE_URL= .venv/bin/python scripts/week2_api_e2e.py
-```
-
-The script starts a real local API server, issues local Flow-compatible tokens,
-runs migrations forward, and exercises:
-
-`Project -> Guide -> Task -> Screening -> Ready -> Claim -> Start -> Pre-submit checks -> pre_submission_checker_failed | Submit -> automatic lock -> evaluation_pending -> review_pending | checker_caused_revision -> needs_revision -> fixed_resubmission -> evaluation_pending -> review_pending | internal task_setup_blocked -> trusted checker retry`
-
-It also proves older submissions remain immutable, non-owning contributor calls create
-no task-side effects, malicious internal fields are rejected before persistence,
-and checker-caused `needs_revision` creates no human review decision.
-
-## Deterministic Week 2 Closeout Gate
-
-The Week 2 closeout gate is deterministic and must fail on contract drift.
-
-Required invariants:
-
-- Real API drills run only against local `postgresql+asyncpg://` test databases named `workstream_test` or `test_workstream` unless an explicit write-risk override is supplied.
-- Pre-submit checker responses are non-authoritative preflight feedback; submission creation is the authoritative intake gate and must not create submissions, checker runs, or lifecycle transitions when blocking failures exist.
-- Missing or unexpected pre-submit checker names fail the drill.
-- Missing or unexpected durable checker names fail the drill.
-- Submission creation returns `finalized_at`, stamps evidence rows, and the
- repair-only finalize endpoint is idempotent.
-- Automatic checker-run creation, checker terminal status, and task-status transitions are polled because execution is async-first.
-- Checker-run list visibility is checked for project manager, assigned contributor, unassigned contributor, and reviewer denial while broad reviewer checker-run access remains deferred.
-- Trusted checker retry proves attempt ordering, supersession, and current-run flags.
-- API-visible invariants are checked after the real API flows for locked guide/policy context, evidence finalization, checker results, checker counters, current-run uniqueness, and gate audit events. The legacy Week 2 regression script still includes direct database assertions; the accepted no-DB proof is the API contract drill plus the Terminal Benchmark API drill.
-
-Week 2 closeout validation is not only this script. The full gate is:
-
-```bash
-.venv/bin/python -m ruff check app tests scripts
-WORKSTREAM_DATABASE_URL= .venv/bin/python scripts/api_contract_e2e.py
-WORKSTREAM_DATABASE_URL= .venv/bin/python scripts/week2_api_e2e.py
-WORKSTREAM_DATABASE_URL= .venv/bin/python -m pytest tests/test_checkers.py tests/test_tasks.py -q
-WORKSTREAM_DATABASE_URL= .venv/bin/python -m pytest -q
-.venv/bin/docstr-coverage --config .docstr.yaml
-```
-
-The closeout also requires stale wording scan, Markdown link check, and internal verifier evidence before PR.
-
-## Operating Rule
-
-No roadmap item is considered closed until it is represented in one of:
-
-- product spec
-- architecture spec
-- operation workflow
-- template
-- checker rule
-- decision record
-- review closure
+The release bar is one secured, observable, end-to-end lifecycle using the
+locked backend and storage architecture. Marketplace expansion, blockchain
+settlement, external source adapters, automated routing, and agent workspaces
+remain outside v0.1.
+
+## Implemented On `main`
+
+### Platform foundation
+
+- FastAPI backend, SQLAlchemy async persistence, Alembic migrations, and
+ PostgreSQL record storage.
+- Async checker and project-setup execution with Celery and Redis where durable
+ retries and isolation are required.
+- Provider-neutral immutable artifact storage with MinIO protocol proof for
+ local development and CI, plus bounded private processing scratch.
+- External integrations composed through the typed ADR 0014 adapter boundary.
+
+### Identity and authorization
+
+- External Flow-token verification with issuer boundaries and request context.
+- Canonical actors, identity links, actor lifecycle controls, and human lineage.
+- Closed permission/action catalogues, deny-by-default authorization, bootstrap
+ administrator grants, fixed-service identities, and runtime admission.
+- Project-role grants, administrative APIs, authority evidence, idempotency,
+ and PostgreSQL-backed rate controls.
+- Project setup and project mutation/read authorization foundations used by the
+ current guide integration work.
+
+### Project, task, submission, and checker foundations
+
+- Project guides, task queue records, task lifecycle guards, work context, and
+ contributor submission requirements.
+- Versioned submission packets with evidence references, locked context,
+ finalization, and contributor privacy boundaries.
+- Typed checker contracts, registry and runner behavior, durable checker
+ records, pre-submit checks, and the automatic pre-review gate.
+- Trusted retry, supersession, audit evidence, and real API contract drills for
+ the implemented lifecycle.
+
+### Guide-source and artifact processing
+
+- Immutable source snapshots, source-media classification, typed extraction
+ boundaries, and persisted extraction results.
+- PDF, DOCX, and XLSX extraction with bounded input handling and OOXML security
+ controls.
+- Image metadata handling and persisted guide-sufficiency evidence.
+- Guide materialization from persisted artifact-processing evidence.
+
+## Integration In Progress
+
+The following areas have merged planning, contracts, or partial foundations,
+but are not all complete as one production path:
+
+- authoritative project-guide binding and read activation across ART and AUTH;
+- reviewed cross-initiative contracts connecting artifact custody with
+ authorization-owned project guide reads;
+- review-policy persistence and activation across REV and AUTH;
+- review queue, reviewer assignment/claim, immutable decisions, and revision
+ replay on the canonical authorization boundary;
+- atomic review-to-contribution and conditional compensation integration.
+
+Open pull requests are the authoritative view of the exact code currently under
+review. Their presence does not change the implemented-on-`main` list above.
+
+## Remaining v0.1 Capability Milestones
+
+1. Complete the production guide binding/read path and prove its authorization,
+ custody, lineage, and stale-generation behavior.
+2. Complete review and revision persistence, queueing, access, decisions,
+ findings, replay, and operational recovery.
+3. Create immutable contributor and reviewer contribution records from the
+ accepted review lifecycle.
+4. Complete contribution-policy evaluation, conditional compensation awards,
+ fulfillment, idempotency, reconciliation, and audit behavior without making
+ settlement a prerequisite.
+5. Preserve authoritative contribution evidence for future reputation
+ projections; reputation projection remains deferred from the v0.1 runtime.
+6. Prove the complete v0.1 lifecycle through real API, database, durable-job,
+ storage, security, and operational recovery tests.
+7. Add the React/Vite/TypeScript product surfaces only against stable and tested
+ backend contracts.
+8. Run a real internal pilot and close findings without weakening lifecycle,
+ authorization, storage, or evidence guarantees.
+
+These are dependency-ordered capability milestones, not a schedule. Distinct
+initiatives may proceed concurrently when their contracts and integration
+boundaries do not conflict.
+
+## How To Read Repository Status
+
+- **Implemented:** code and required evidence are merged on `main`.
+- **In progress:** a bounded branch or pull request exists; behavior is not yet
+ part of `main`.
+- **Planned:** an accepted specification or initiative describes future work;
+ behavior is unavailable until implemented and merged.
+- **Historical:** the document records prior intent or evidence and does not
+ control current work.
+
+Use [CONTRIBUTING.md](../CONTRIBUTING.md) to start work and the
+[Historical Planning Index](historical_planning.md) when investigating earlier
+decisions.
diff --git a/docs/roadmap_week1_backend_plan.md b/docs/roadmap_week1_backend_plan.md
index 77fd288fe..e1dd3174f 100644
--- a/docs/roadmap_week1_backend_plan.md
+++ b/docs/roadmap_week1_backend_plan.md
@@ -1,5 +1,9 @@
# Week 1 Backend Plan
+> Historical planning record. This calendar no longer controls current work or
+> status. Use [Current v0.1 Status](roadmap_status.md) and the
+> [Historical Planning Index](historical_planning.md).
+
## Purpose
This is the implementation plan for the June 2-5 foundation work.
diff --git a/docs/spec_chunk_10_checker_trial.md b/docs/spec_chunk_10_checker_trial.md
index 14455f8cd..89a7b65a7 100644
--- a/docs/spec_chunk_10_checker_trial.md
+++ b/docs/spec_chunk_10_checker_trial.md
@@ -1,5 +1,8 @@
# Chunk 10 Checker Trial
+> Historical validation record. It does not define current sequencing or
+> status; later canonical specifications and merged behavior take precedence.
+
## Purpose
Chunk 10 proves the Week 2 checker framework against real sample submission flows.
diff --git a/docs/spec_chunk_5_submission_packet_foundation.md b/docs/spec_chunk_5_submission_packet_foundation.md
index 7bb07008f..4951bfea0 100644
--- a/docs/spec_chunk_5_submission_packet_foundation.md
+++ b/docs/spec_chunk_5_submission_packet_foundation.md
@@ -1,5 +1,8 @@
# Chunk 5: Submission Packet Foundation
+> Historical implementation record. It does not define current sequencing or
+> status; later canonical specifications and merged behavior take precedence.
+
## Purpose
This chunk adds the backend record for Contributor submission packets. A
diff --git a/docs/spec_chunk_6_checker_contract_records.md b/docs/spec_chunk_6_checker_contract_records.md
index 84e19b057..da2f1c21e 100644
--- a/docs/spec_chunk_6_checker_contract_records.md
+++ b/docs/spec_chunk_6_checker_contract_records.md
@@ -1,5 +1,8 @@
# Chunk 6: Checker Contract And Records
+> Historical implementation record. It does not define current sequencing or
+> status; later canonical specifications and merged behavior take precedence.
+
## Purpose
Chunk 6 creates the durable checker run and checker result contract for Week 2.
diff --git a/docs/spec_chunk_7_checker_runner_registry.md b/docs/spec_chunk_7_checker_runner_registry.md
index def207a26..7541b40c5 100644
--- a/docs/spec_chunk_7_checker_runner_registry.md
+++ b/docs/spec_chunk_7_checker_runner_registry.md
@@ -1,5 +1,8 @@
# Chunk 7: Checker Runner And Registry
+> Historical implementation record. It does not define current sequencing or
+> status; later canonical specifications and merged behavior take precedence.
+
## Purpose
Chunk 7 turns the checker contract into a working backend slice.
diff --git a/docs/spec_chunk_8_submission_artifact_policy_checkers.md b/docs/spec_chunk_8_submission_artifact_policy_checkers.md
index b119f8738..f9b11d344 100644
--- a/docs/spec_chunk_8_submission_artifact_policy_checkers.md
+++ b/docs/spec_chunk_8_submission_artifact_policy_checkers.md
@@ -1,5 +1,8 @@
# Chunk 8: Submission Artifact And Policy Checkers
+> Historical implementation record. It does not define current sequencing or
+> status; later canonical specifications and merged behavior take precedence.
+
## Purpose
Chunk 8 expands the checker registry from the first structural runner into the first policy-aware submission artifact gate.
diff --git a/docs/spec_chunk_9_pre_review_gate.md b/docs/spec_chunk_9_pre_review_gate.md
index d16c5eb8f..9aa23f36b 100644
--- a/docs/spec_chunk_9_pre_review_gate.md
+++ b/docs/spec_chunk_9_pre_review_gate.md
@@ -1,5 +1,8 @@
# Chunk 9 Pre-Review Gate
+> Historical implementation record. It does not define current sequencing or
+> status; later canonical specifications and merged behavior take precedence.
+
## Purpose
Chunk 9 makes internal post-submit checks automatic.
diff --git a/docs/spec_week2_checker_framework.md b/docs/spec_week2_checker_framework.md
index f3a9608ff..8bdfac7bf 100644
--- a/docs/spec_week2_checker_framework.md
+++ b/docs/spec_week2_checker_framework.md
@@ -1,5 +1,9 @@
# Week 2 Checker Framework Specification
+> Historical implementation specification. It is preserved as evidence of the
+> early checker build, not as current sequencing or status. Use
+> [Current v0.1 Status](roadmap_status.md) and canonical subsystem documents.
+
## Purpose
Week 2 adds the automated checker boundary between locked submissions and human review.