Propose governed self-development v1

dev/ACTIVE_TASK.json

@@ -1,5 +1,5 @@
 {
-  "task_file": "dev/tasks/DEV-000105-multi-agent-work-graph-proposal.json",
-  "task_id": "DEV-000105",
+  "task_file": "dev/tasks/DEV-000106-governed-self-development-proposal.json",
+  "task_id": "DEV-000106",
   "task_revision": 1
 }

dev/tasks/DEV-000106-governed-self-development-proposal.json

@@ -0,0 +1,23 @@
+{
+  "task_id": "DEV-000106",
+  "task_revision": 1,
+  "architecture_revision": "ADR-0018",
+  "base_repo_revision": "08deab8",
+  "risk_tier": "E",
+  "intent": "Prepare the proposed ADR-0022 Governed Self-Development boundary for review without implementing proposal generation, factories, candidate activation or production changes.",
+  "requirement_ids": ["WP-600", "Governed development control plane", "Candidate canary promotion rollback emergency stop"],
+  "allowed_change_scope": {"modules": ["governed-development-proposal"], "paths": ["docs/proposals/ADR-0022-governed-self-development-v1.md", "dev/ACTIVE_TASK.json", "dev/tasks/DEV-000106-governed-self-development-proposal.json"]},
+  "forbidden_change_scope": {"paths": ["architecture/**", "contracts/**", "database/**", "migrations/**", "modules/**", "cmd/**", "runtime/**", "adapters/**", "deploy/**", ".gitea/**", "skills/**"]},
+  "allowed_architecture_delta": {"new_cross_module_dependencies": 0, "new_canonical_owners": 0, "new_privileges": 0, "new_third_party_dependencies": 0, "new_database_owner_roles": 0},
+  "contracts": {"consume": ["ADR-0016 Experience/Reflection/Skill Evolution", "Proposed ADR-0019 Truth V1 evidence", "Proposed ADR-0020 Agent Execution Plane", "Proposed ADR-0021 Work Graph", "existing Authority/Commit/Artifact boundaries"], "may_change": ["Proposed ADR-0022 only; no accepted contract changes"]},
+  "semantic_owner": "governed-development-proposal-only",
+  "canonical_state": [],
+  "state_transitions": ["evidence -> proposal -> sandbox -> evaluation -> canary -> promotion/rollback/retirement", "failed/conflicted/incomplete evaluation -> blocked"],
+  "side_effects_and_privileges": ["No runtime side effects, source mutation, deployment, external mutation, credential access or authority expansion"],
+  "persistence_and_migrations": ["No proposal store, candidate artifact store, schema, migration or telemetry implementation changes"],
+  "failure_retry_restart": ["Candidate evidence and lineage survive rejection/rollback; emergency stop disables candidate selection without deleting history"],
+  "assumptions": ["Human governance remains promotion authority", "Protected paths and secret policies cannot be modified by the control plane", "New code/model/skill never receives authority automatically"],
+  "acceptance_scenarios": ["One failure cannot create a proposal", "Candidate lineage and isolated scope are mandatory", "Independent evaluation and verifier are explicit", "Canary and rollback preserve previous implementation and evidence", "Emergency stop blocks candidate traffic", "No implementation or registry delta is introduced"],
+  "required_tests": ["go test ./...", "go vet ./...", "go run ./cmd/devctl preflight -active dev/ACTIVE_TASK.json", "go run ./cmd/devctl check-diff -active dev/ACTIVE_TASK.json", "go run ./cmd/devctl check-architecture", "go run ./cmd/devctl/independent", "git diff --check", "proposal scope and required-section review"],
+  "terminal_gap_states": ["BLOCKED_BY_ARCHITECTURE_GAP", "BLOCKED_BY_SPEC_GAP", "BLOCKED_BY_CONFLICT"]
+}

docs/proposals/ADR-0022-governed-self-development-v1.md

@@ -0,0 +1,79 @@
+# Proposal ADR-0022 — Governed Self-Development V1
+
+Status: Proposed
+Task: DEV-000106
+
+## Problem and evidence
+
+The audit found ReflectionCandidates and capability evidence, but no safe
+pipeline for turning repeated evidence into a reviewed change. Direct
+self-editing would let model output alter source, skills, authority or
+production without provenance, evaluation or rollback.
+
+## Decision proposed
+
+1. Introduce a governed development control plane. `ExtensionProposal` is an
+   evidence-bearing request that moves through review, implementation and
+   promotion stages.
+2. A proposal must reference repeated or corroborated evidence, desired
+   outcome, smallest change layer, affected owners/contracts, assumptions,
+   alternatives, risk tier, evaluation plan, rollback and emergency-stop
+   conditions. One accidental failure is insufficient; duplicate evidence is
+   deduplicated without deleting its history.
+3. Candidate artifacts are immutable, content-addressed and lineage-linked to
+   the proposal, task packet, source revision, generator/author identity,
+   tests, evaluations and environment. Candidate code, skill, adapter or
+   configuration is created only in an isolated branch/worktree/sandbox with
+   no protected-main, production or ambient-secret access.
+4. A human-authorized governance boundary approves task scope and promotion.
+   Cognitive components may propose and summarize evidence; promotion remains
+   an explicit governance decision.
+5. Evaluation is layered: contract/architecture/security checks, deterministic
+   unit/integration tests, adversarial and regression corpus, migration/
+   recovery checks, and independent verifier review. Failed, conflicting or
+   incomplete evidence blocks promotion and remains attributable.
+6. Candidate lifecycle is explicit: `PROPOSED`, `REJECTED`, `SANDBOXED`,
+   `EVALUATING`, `CANARY`, `PROMOTED`, `ROLLED_BACK`, `RETIRED` and `BLOCKED`.
+   Promotion is bounded by capability registration, traffic, budget and
+   telemetry policy. A candidate never receives authority merely by passing
+   model evaluation.
+7. Canary state keeps the previous implementation addressable. Rollback is a
+   durable, reversible selection change with an emergency stop that disables
+   candidate traffic without deleting evidence, artifacts or lineage.
+8. Generated skills, modules, adapters and configuration follow the same
+   ordinary development path: typed owners, task scope, architecture checks,
+   tests, security review, migration/recovery plan and independent
+   verification.
+
+## Ownership and boundaries
+
+Epistemics owns evidence and ReflectionCandidates; Capability owns
+implementation/skill registration and lifecycle; Work owns task/delegation
+execution; Artifact owns candidate and evaluation metadata; Authority owns
+human promotion permission; Commit/Executor owns external mutation. No new
+universal LearningManager or self-development owner is introduced.
+
+Three boundaries are essential: candidate work uses the declared task scope,
+secret access follows existing CredentialRef policy, and candidate promotion
+does not itself grant new authority. Original intent, truth assessments and
+historical evidence retain their existing owners and provenance.
+
+## Rationale
+
+Evidence, scoped implementation, independent evaluation and reversible
+promotion provide a practical improvement loop while keeping authority and
+provenance explicit. The design uses existing Epistemics, Capability, Work,
+Artifact and Authority boundaries instead of adding a new universal manager.
+
+## Consequences, migration and rollback
+
+The proposal creates an auditable path for improvement while adding review,
+evaluation and artifact-retention cost. There is no implementation, schema or
+production change here. Implementation starts with a deterministic proposal
+fixture and fake candidate, then uses opt-in canary traffic. Rollback disables
+candidate selection and restores the previous implementation reference;
+evidence and failed candidates remain available for analysis.
+
+Revisit if a candidate requires new authority, cross-owner direct storage,
+unreviewed external mutation, or if rollback cannot restore the previous
+implementation deterministically.