create-agdf 0.3.4 → 0.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (33) hide show
  1. package/README.md +29 -11
  2. package/bin/create-agdf.js +546 -32
  3. package/generated/.agdf/control/templates/AGDF_RUN.md +29 -0
  4. package/generated/.agdf/control/templates/AGENT_QUALITY_CONTRACTS.json +48 -0
  5. package/generated/.agdf/control/templates/MASTER_BACKLOG.md +7 -10
  6. package/generated/.agdf/control/templates/artefacts/OR.md +20 -4
  7. package/generated/.github/skills/agdf-gate-check/SKILL.md +7 -0
  8. package/generated/.github/skills/agdf-release-or/SKILL.md +2 -0
  9. package/generated/.github/skills/agdf-runtime-contract.md +132 -0
  10. package/generated/.opencode/AGDF.md +8 -0
  11. package/generated/.opencode/README.md +4 -0
  12. package/generated/.opencode/agdf-runtime-contract.md +132 -0
  13. package/generated/.opencode/agents/agdf-brownfield-analysis.md +0 -5
  14. package/generated/.opencode/agents/agdf-clean-implementation-review.md +0 -5
  15. package/generated/.opencode/agents/agdf-code-review.md +0 -5
  16. package/generated/.opencode/agents/agdf-delivery-closeout.md +0 -5
  17. package/generated/.opencode/agents/agdf-gate-check.md +7 -5
  18. package/generated/.opencode/agents/agdf-qa-gate.md +0 -5
  19. package/generated/.opencode/agents/agdf-release-or.md +2 -5
  20. package/generated/.opencode/agents/agdf-task-plan-review.md +0 -5
  21. package/generated/AGENTS.md +4 -0
  22. package/generated/plugins/agdf/.codex-plugin/plugin.json +1 -1
  23. package/generated/plugins/agdf/control/templates/AGDF_RUN.md +29 -0
  24. package/generated/plugins/agdf/control/templates/AGENT_QUALITY_CONTRACTS.json +48 -0
  25. package/generated/plugins/agdf/control/templates/MASTER_BACKLOG.md +7 -10
  26. package/generated/plugins/agdf/control/templates/artefacts/OR.md +20 -4
  27. package/generated/plugins/agdf/meta/agdf-agent-router.md +4 -0
  28. package/generated/plugins/agdf/meta/agdf-plugin.definition.json +1 -1
  29. package/generated/plugins/agdf/meta/agdf-runtime-contract.md +132 -0
  30. package/generated/plugins/agdf/skills/gate-check/SKILL.md +7 -0
  31. package/generated/plugins/agdf/skills/release-or/SKILL.md +2 -0
  32. package/opencode-plugin.js +16 -2
  33. package/package.json +1 -1
@@ -3,11 +3,6 @@ description: new build/change intent, unclear approval, Structured Delivery, lat
3
3
  mode: subagent
4
4
  ---
5
5
 
6
- ---
7
- name: agdf-gate-check
8
- description: Use this skill as the default first AGDF skill for any new build, change, extension, refactor, feature, CLI, app, fix with product semantics, Structured Delivery request, unclear approval, later-gate artefact request, or unclear next permissible step. Use it before brownfield-analysis, implementation, formal artefacts, QA, or release when approval/evidence/next action is not already explicit.
9
- ---
10
-
11
6
  # gate-check
12
7
 
13
8
  ## Purpose
@@ -73,6 +68,10 @@ The CLI reports are validators and JSON evidence, not the primary user experienc
73
68
  13. After Brownfield Review, decide the process size before drafting PRD or implementing: `quick_task | structured_slice | structured_delivery | block`.
74
69
  14. The Mode/Slice Decision must be visible and evidenced before any Quick Task execution, PRD shortcut or implementation. A decision value without scope reason and evidence is still missing.
75
70
  15. Missing or incomplete control state must not push setup work back to the user. For a fresh request, draft the current minimal artefact in the response and request the exact approval. Initialize or write `.agdf/control/` only when durable control state is explicitly requested, already live for the repository, or required for a deterministic CLI/CI setup path. Implementation remains forbidden.
71
+ 16. Branch names, uncommitted diffs, generated summaries and chat history are not sufficient scope proof when durable artefacts or approvals are missing or conflicting.
72
+ 17. If multiple active scopes are plausible, list the evidenced competing lines and keep the current step at scope clarification or the earliest common safe gate.
73
+ 18. When maintaining `MASTER_BACKLOG.md`, use its canonical compact columns, readable status labels and document-relative Markdown links. Do not expose raw long paths or internal snake_case statuses in the human-facing table.
74
+ 19. Preserve legacy backlog compatibility through the CLI parser; do not create a second surface-specific backlog format.
76
75
 
77
76
  ## Gate Evaluation
78
77
 
@@ -105,6 +104,8 @@ Use what is available:
105
104
  - Brownfield Analysis status
106
105
  - CD+Tests, CR, QA, UAT status
107
106
  - signs of documentation/runtime/product-semantics drift
107
+ - branch/workspace evidence and whether it conflicts with durable artefacts
108
+ - competing active scopes or work lines
108
109
 
109
110
  If a status is not explicit, do not assume it is satisfied.
110
111
 
@@ -120,6 +121,7 @@ If a status is not explicit, do not assume it is satisfied.
120
121
  9. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
121
122
  10. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
122
123
  11. When `.agdf/control/` is missing or incomplete, make the next allowed artefact action explicit. For a fresh request, that means draft the minimal UR in the response, then request `Approval: UR`. Do not write a full control scaffold unless durable control state was explicitly requested or is already the repository's live AGDF working state.
124
+ 12. If branch, workspace and durable artefacts disagree, do not choose a scope silently; report the ambiguity and ask for the smallest clarifying gate action.
123
125
 
124
126
  ## Output
125
127
  Keep the result short and operational:
@@ -3,11 +3,6 @@ description: final QA decision
3
3
  mode: subagent
4
4
  ---
5
5
 
6
- ---
7
- name: agdf-qa-gate
8
- description: Use this skill before any QA decision to determine whether implementation can be classified as pass, revise, or block based on TP coverage, Brownfield fit, solution integrity, evidence, and open blockers. Use it after CD+Tests, after reviews, and before UAT or release decisions.
9
- ---
10
-
11
6
  # qa-gate
12
7
 
13
8
  ## Purpose
@@ -3,11 +3,6 @@ description: auditable closeout for every relevant run
3
3
  mode: subagent
4
4
  ---
5
5
 
6
- ---
7
- name: agdf-release-or
8
- description: Use this skill at the end of every relevant run to produce a compact, auditable Orchestration Report. It summarizes gate status, delivered and intentionally not delivered work, TP coverage, Brownfield fit, solution integrity, open risks, and the next permissible step.
9
- ---
10
-
11
6
  # release-or
12
7
 
13
8
  ## Purpose
@@ -47,6 +42,8 @@ Use the Runtime Contract definition of `Relevant Run` to decide whether OR is ma
47
42
  8. Retained fallbacks require visible exit criteria and cleanup path.
48
43
  9. End with the immediately permissible next step.
49
44
  10. `CD+Tests` is not completion.
45
+ 11. When moving a backlog item to Completed or Superseded, use the canonical human-readable table and link the final OR with a document-relative Markdown link.
46
+ 12. Keep machine status normalization in the CLI; do not write internal snake_case status values into the human-facing backlog.
50
47
 
51
48
  ## When To Use
52
49
  - at the end of every relevant run
@@ -3,11 +3,6 @@ description: after implementation and before QA, verify TP coverage
3
3
  mode: subagent
4
4
  ---
5
5
 
6
- ---
7
- name: agdf-task-plan-review
8
- description: Use this skill after code changes and before QA to verify whether the approved Task Plan was actually fulfilled. It checks each task_id against implementation, acceptance criteria, tests, visible evidence, and deviations, and provides TP coverage for QA.
9
- ---
10
-
11
6
  # task-plan-review
12
7
 
13
8
  ## Purpose
@@ -34,12 +34,15 @@ Persist it in `.agdf/control/` or link it from there to the target repository's
34
34
  Treat approval text and durable artefact presence as separate checks for UR, PRD, SD, TP and QA report decisions.
35
35
  Do not infer approval from "ok", "go ahead", "do it", "approved", "continue", "leg los" or similar wording.
36
36
  Those phrases may express intent to proceed, but they do not unlock a gate unless the exact gate formula is present.
37
+ Do not infer active scope from branch names, uncommitted workspace deltas, chat history or generated summaries when durable artefacts point elsewhere.
38
+ If multiple active scopes are plausible, list the evidenced lines and route to `agdf-gate-check` or workstate clarification instead of choosing silently.
37
39
  After `Approval: UR`, run lightweight Brownfield Review before PRD when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible.
38
40
  Brownfield Review must produce a Mode/Slice Decision: `quick_task`, `structured_slice`, `structured_delivery` or `block`.
39
41
  Make that decision visible before coding or drafting later artefacts: state the selected path, scope reason, evidence and next required gate in the live control state or linked artefact.
40
42
  Do not assume the full PRD/SD/TP chain before that decision; use only as much gate depth as the reviewed change size justifies.
41
43
 
42
44
  Quick Task Mode must still use the Runtime Contract mini-output: `result`, `evidence`, `risk`, `next_step`.
45
+ Narrow defect work may use the Runtime Contract's Bug Lightweight Track only when a durable bug artefact or linked authoritative issue carries reproduction, actual behavior, expected behavior, fix boundary and evidence plan.
43
46
  Structured Delivery Mode must respect gates, reviews and closeout discipline.
44
47
 
45
48
  ## Skill Routing
@@ -75,6 +78,7 @@ Do not let chat history become the source of truth for gate state, approvals, ev
75
78
  AGDF is agent-native first and CLI-verifiable by design: read the live control state, apply the active skill and make the next allowed step explicit.
76
79
  Use `init` only when durable control state is explicitly requested, the repository already uses `.agdf/control/` as its live AGDF working state, or a deterministic CLI/CI setup path is being executed.
77
80
  Use `doctor --json`, `gate-check --json` or `delivery-map --json` as deterministic validators for CI, PR evidence, regression checks or audit trails, not as a substitute for the router or skills.
81
+ At run closeout, route new durable knowledge explicitly as `context_graph`, `sot_registry`, `scope_artifact`, `open_questions` or `none`.
78
82
 
79
83
  ## Closeout
80
84
  For Quick Task Mode, close with the Runtime Contract mini-output only:
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agdf",
3
- "version": "0.3.4",
3
+ "version": "0.4.0",
4
4
  "description": "Codex-first workflow skills for gated, auditable AI-assisted software delivery.",
5
5
  "author": {
6
6
  "name": "AI-native Governance & Delivery Framework",
@@ -23,6 +23,29 @@ What outcome is this run trying to make trustworthy?
23
23
  | What is the next allowed action? | |
24
24
  | What is explicitly forbidden right now? | |
25
25
 
26
+ ## Source And Scope State
27
+
28
+ - normative_instruction_source:
29
+ - multi_scope_state: `clear | ambiguous | blocked`
30
+ - active_scope_evidence:
31
+ - competing_scope_lines:
32
+ - branch_workspace_evidence:
33
+ - branch_workspace_scope_effect: `supports | conflicts | insufficient | not_checked`
34
+
35
+ ## Run Status Card
36
+
37
+ This is a compact projection of the control state. It does not replace gate-check, QA, OR or approvals.
38
+
39
+ | Run status | Value |
40
+ |---|---|
41
+ | Status | |
42
+ | Current gate | |
43
+ | Allowed now | |
44
+ | Blocked by | |
45
+ | Missing approval | |
46
+ | Next step | |
47
+ | Quality outlook | |
48
+
26
49
  ## Approvals
27
50
 
28
51
  Valid approval format for new runs: `Approval: <GateName>`.
@@ -98,6 +121,12 @@ Keep the active work item traceable. A gate may open only when the previous gate
98
121
  - context_graph_gate_effect: `none | warning | revise | block`
99
122
  - context_graph_evidence:
100
123
 
124
+ ## Knowledge Persistence Decision
125
+
126
+ - memory_target: `context_graph | sot_registry | scope_artifact | open_questions | none`
127
+ - memory_reason:
128
+ - memory_refs:
129
+
101
130
  ## Closeout
102
131
 
103
132
  - delivered:
@@ -73,6 +73,54 @@
73
73
  "required_evidence": ["closeout_note"],
74
74
  "evaluation": "review",
75
75
  "owner": "governance"
76
+ },
77
+ {
78
+ "code": "AGDF_SCOPE_AMBIGUOUS",
79
+ "category": "agent_process",
80
+ "impact": "revise",
81
+ "title": "Ambiguous active scope",
82
+ "description": "Multiple active work lines are plausible and the agent must not choose one silently.",
83
+ "applies_to_modes": ["structured_delivery", "quick_task"],
84
+ "gate_effect": ["ur", "prd", "sd", "tp", "qa"],
85
+ "required_evidence": ["competing_scope_lines", "active_scope_evidence"],
86
+ "evaluation": "review",
87
+ "owner": "governance"
88
+ },
89
+ {
90
+ "code": "AGDF_BRANCH_NOT_SCOPE_PROOF",
91
+ "category": "agent_process",
92
+ "impact": "warn",
93
+ "title": "Branch or workspace is not scope proof",
94
+ "description": "Branch names and workspace deltas may support a scope only when they do not conflict with durable artefacts or approvals.",
95
+ "applies_to_modes": ["structured_delivery", "quick_task"],
96
+ "gate_effect": ["ur", "prd", "sd", "tp", "qa"],
97
+ "required_evidence": ["branch_workspace_evidence", "artefact_status"],
98
+ "evaluation": "review",
99
+ "owner": "governance"
100
+ },
101
+ {
102
+ "code": "AGDF_MEMORY_TARGET_MISSING",
103
+ "category": "agent_process",
104
+ "impact": "warn",
105
+ "title": "Knowledge persistence decision missing",
106
+ "description": "A relevant run ended without deciding whether new durable knowledge belongs in the Context Graph, SoT registry, scope artefact, open questions or nowhere.",
107
+ "applies_to_modes": ["structured_delivery", "quick_task"],
108
+ "gate_effect": ["or"],
109
+ "required_evidence": ["memory_target", "memory_reason"],
110
+ "evaluation": "review",
111
+ "owner": "governance"
112
+ },
113
+ {
114
+ "code": "AGDF_BUG_LIGHTWEIGHT_SCOPE_UNEVIDENCED",
115
+ "category": "scope_control",
116
+ "impact": "revise",
117
+ "title": "Bug Lightweight Track lacks bug evidence",
118
+ "description": "A lightweight defect path requires durable reproduction, actual behavior, expected behavior, fix boundary, open questions and evidence plan.",
119
+ "applies_to_modes": ["quick_task"],
120
+ "gate_effect": ["qa"],
121
+ "required_evidence": ["bug_artifact_or_issue", "reproduction", "expected_behavior", "evidence_plan"],
122
+ "evaluation": "review",
123
+ "owner": "governance"
76
124
  }
77
125
  ]
78
126
  }
@@ -5,31 +5,28 @@ This file is the living control pointer for active AGDF delivery work. Detailed
5
5
  ## Rules
6
6
 
7
7
  1. New product semantics, functional change or user-visible behaviour change starts as a new UR draft in a stable local artefact path, for example `.agdf/control/artefacts/<key>/UR.md`, unless an authoritative repository SoT already exists and is linked here.
8
- 2. `Approval: UR` adds or updates exactly one steering row with a link to the UR.
8
+ 2. `Approval: UR` adds or updates exactly one steering row with a document-relative Markdown link to the UR.
9
9
  3. Brownfield Review is created for the same work item after UR approval when existing-system impact must be sized before PRD depth or Quick Task execution.
10
10
  4. PRD, SD, TP and QA report artefacts are created for the same work item after the previous gate is approved and persisted or linked.
11
11
  5. `Approval: PRD`, `Approval: SD`, `Approval: TP` and `Approval: QA` require the corresponding durable artefact or linked repository SoT before the next gate can open.
12
12
  6. Generic consent such as "ok", "go ahead", "do it", "continue", "leg los" or "approved" does not update a gate. Only `Approval: <GateName>` does.
13
13
  7. Keep only steering-relevant work in `Active Backlog`.
14
- 8. Every active item has exactly one current spec pointer and a visible artefact chain.
14
+ 8. Every active item has exactly one linked current spec and a visible linked artefact chain.
15
15
  9. Historical artefacts remain linkable but do not override the current pointer.
16
16
  10. If an item is superseded, mark the replacement.
17
17
  11. If active work grows beyond roughly ten items, triage the backlog.
18
18
 
19
19
  ## Active Backlog
20
20
 
21
- | Prio | Key | Title | Status | UR | Brownfield Review | PRD | SD | TP | QA | OR | Current Spec | Notes |
22
- |---:|---|---|---|---|---|---|---|---|---|---|---|---|
23
- | P1 | | | `in_progress | blocked` | | | | | | | | | |
21
+ | Priority | Key | Work item | Status | Artefacts | Current spec | Next step |
22
+ |---:|---|---|---|---|---|---|
24
23
 
25
24
  ## Planned / Parking Lot
26
25
 
27
- | Prio | Key | Title | Status | UR | Brownfield Review | PRD | SD | TP | QA | OR | Current Spec | Notes |
28
- |---:|---|---|---|---|---|---|---|---|---|---|---|---|
29
- | P2 | | | `planned | review_needed` | | | | | | | | | |
26
+ | Priority | Key | Work item | Status | Artefacts | Current spec | Next step |
27
+ |---:|---|---|---|---|---|---|
30
28
 
31
29
  ## Completed / Superseded Pointers
32
30
 
33
- | Key | Title | Final Status | Current or Historical Link | Notes |
31
+ | Key | Work item | Final status | Historical record | Outcome |
34
32
  |---|---|---|---|---|
35
- | | | `done | superseded | abandoned` | | |
@@ -33,6 +33,20 @@ Status: `draft | done | superseded`
33
33
  | QA | | |
34
34
  | UAT | | |
35
35
 
36
+ ## Run Status Card
37
+
38
+ This is a compact projection of the control state. It does not replace gate-check, QA, OR or approvals.
39
+
40
+ | Run status | Value |
41
+ |---|---|
42
+ | Status | |
43
+ | Current gate | |
44
+ | Allowed now | |
45
+ | Blocked by | |
46
+ | Missing approval | |
47
+ | Next step | |
48
+ | Quality outlook | |
49
+
36
50
  ## Delivered
37
51
 
38
52
  | Item | Evidence |
@@ -71,16 +85,18 @@ Status: `draft | done | superseded`
71
85
  - context_graph_gate_effect: `none | warning | revise | block`
72
86
  - context_graph_evidence:
73
87
 
88
+ ## Knowledge Persistence Decision
89
+
90
+ - memory_target: `context_graph | sot_registry | scope_artifact | open_questions | none`
91
+ - memory_reason:
92
+ - memory_refs:
93
+
74
94
  ## Next Permissible Step
75
95
 
76
96
  - next_allowed_action:
77
97
  - required_approval:
78
98
  - forbidden_until_then:
79
99
 
80
- ## Quality Outlook
81
-
82
- - quality_outlook:
83
-
84
100
  ## Approval
85
101
 
86
102
  OR does not approve later gates. It records the next permissible step.
@@ -35,12 +35,15 @@ Persist it in `.agdf/control/` or link it from there to the target repository's
35
35
  Treat approval text and durable artefact presence as separate checks for UR, PRD, SD, TP and QA report decisions.
36
36
  Do not infer approval from "ok", "go ahead", "do it", "approved", "continue", "leg los" or similar wording.
37
37
  Those phrases may express intent to proceed, but they do not unlock a gate unless the exact gate formula is present.
38
+ Do not infer active scope from branch names, uncommitted workspace deltas, chat history or generated summaries when durable artefacts point elsewhere.
39
+ If multiple active scopes are plausible, list the evidenced lines and route to `gate-check` or workstate clarification instead of choosing silently.
38
40
  After `Approval: UR`, run lightweight Brownfield Review before PRD when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible.
39
41
  Brownfield Review must produce a Mode/Slice Decision: `quick_task`, `structured_slice`, `structured_delivery` or `block`.
40
42
  Make that decision visible before coding or drafting later artefacts: state the selected path, scope reason, evidence and next required gate in the live control state or linked artefact.
41
43
  Do not assume the full PRD/SD/TP chain before that decision; use only as much gate depth as the reviewed change size justifies.
42
44
 
43
45
  Quick Task Mode must still use the Runtime Contract mini-output: `result`, `evidence`, `risk`, `next_step`.
46
+ Narrow defect work may use the Runtime Contract's Bug Lightweight Track only when a durable bug artefact or linked authoritative issue carries reproduction, actual behavior, expected behavior, fix boundary and evidence plan.
44
47
  Structured Delivery Mode must respect gates, reviews and closeout discipline.
45
48
 
46
49
  ## Skill Routing
@@ -76,6 +79,7 @@ Do not let chat history become the source of truth for gate state, approvals, ev
76
79
  AGDF is agent-native first and CLI-verifiable by design: read the live control state, apply the active skill and make the next allowed step explicit.
77
80
  Use `init` only when durable control state is explicitly requested, the repository already uses `.agdf/control/` as its live AGDF working state, or a deterministic CLI/CI setup path is being executed.
78
81
  Use `doctor --json`, `gate-check --json` or `delivery-map --json` as deterministic validators for CI, PR evidence, regression checks or audit trails, not as a substitute for the router or skills.
82
+ At run closeout, route new durable knowledge explicitly as `context_graph`, `sot_registry`, `scope_artifact`, `open_questions` or `none`.
79
83
 
80
84
  ## Closeout
81
85
  For Quick Task Mode, close with the Runtime Contract mini-output only:
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "schemaVersion": 1,
3
3
  "id": "agdf",
4
- "version": "0.3.4",
4
+ "version": "0.4.0",
5
5
  "displayName": "AI Governance & Delivery Framework",
6
6
  "developerName": "AI-native Governance & Delivery Framework",
7
7
  "description": "Codex-first workflow skills for gated, auditable AI-assisted software delivery.",
@@ -27,6 +27,118 @@ Use this compact output shape when no formal gate artefact is required:
27
27
 
28
28
  Do not add a separate `Quality outlook` line for pure Quick Tasks unless the task became a relevant run.
29
29
 
30
+ ## Run Status Card
31
+
32
+ When a run needs an operational status view, use the Run Status Card as a compact projection of existing control state.
33
+ It must not introduce a second gate model or override `gate-check`, `delivery-map`, QA, OR, or user approvals.
34
+
35
+ - `mode`: `quick_task | structured_delivery | unknown`
36
+ - `status`: `open | blocked | pass | warn | revise | block | in_progress`
37
+ - `current_gate`: current user gate or internal step
38
+ - `mode_slice_decision`: `undecided | quick_task | structured_slice | structured_delivery | block`
39
+ - `allowed_now`: outputs or actions currently permitted
40
+ - `forbidden_now`: outputs or actions currently forbidden
41
+ - `blocking_condition`: current blocker or `none`
42
+ - `missing_approval`: exact missing approval formula or `none`
43
+ - `evidence`: concrete evidence references currently visible
44
+ - `next_skill`: next AGDF skill or `none`
45
+ - `next_step`: the single next permissible process action
46
+ - `quality_outlook`: the next meaningful quality-improvement focus, or `none`
47
+
48
+ `next_step` and `quality_outlook` are intentionally different:
49
+
50
+ - `next_step` is process permission: what may happen next.
51
+ - `quality_outlook` is quality direction: what would most improve confidence, maintainability, evidence, or delivery integrity if further investment is made.
52
+
53
+ `quality_outlook` must not unlock gates, imply QA pass, or substitute for missing evidence.
54
+
55
+ The field names above are the stable machine-readable contract used by JSON
56
+ reports and automation. Human-facing Markdown must present the same projection
57
+ with readable labels such as `Current gate`, `Allowed now`, `Blocked by`,
58
+ `Next step` and `Quality outlook`; do not expose snake_case keys as the visible
59
+ Run Status Card. Keep that card compact: show `Status`, `Current gate`,
60
+ `Allowed now`, `Blocked by`, `Missing approval`, `Next step` and
61
+ `Quality outlook`. Keep mode, forbidden actions, evidence and next-skill detail
62
+ in the surrounding control artefact when they are relevant.
63
+
64
+ ## Source Precedence
65
+
66
+ Every governed repository should make the normative instruction source visible.
67
+ When several instruction files, generated copies, submodule rules, branch names, worktree diffs or chat summaries point in different directions, fail closed instead of inventing a primary authority.
68
+
69
+ Default precedence:
70
+
71
+ 1. safety, security and compliance instructions
72
+ 2. repository-declared normative agent instructions
73
+ 3. live `.agdf/control/` state or a linked authoritative repository SoT
74
+ 4. approved gate artefacts
75
+ 5. source code and verified runtime evidence
76
+ 6. branch names, workspace deltas, chat history and model memory
77
+
78
+ A branch name or uncommitted workspace delta is never sufficient scope proof by itself.
79
+ It may support a scope only when it does not conflict with durable artefacts, approvals or source-of-truth records.
80
+
81
+ ## Workstate And Scope Ambiguity
82
+
83
+ If a repository contains multiple plausible active work lines, the agent must not silently choose one.
84
+ List the evidenced competing lines with their latest known gate, artefact pointers, approvals and missing evidence.
85
+ The next permissible step is scope clarification or the earliest common safe gate.
86
+
87
+ Use `multi_scope_state: clear | ambiguous | blocked` when the control state needs to make this visible.
88
+ `ambiguous` is at least a revise condition for delivery-map style reporting.
89
+ `blocked` applies when continuing would produce later-gate artefacts, implementation or release claims for the wrong scope.
90
+
91
+ ## Knowledge Persistence Decision
92
+
93
+ Every relevant run should decide what happens to new durable knowledge.
94
+ The decision is not a memory dump; it routes only reusable, evidenced information to the right owner.
95
+
96
+ Use:
97
+
98
+ - `memory_target: context_graph | sot_registry | scope_artifact | open_questions | none`
99
+ - `memory_reason`: short reason for the target
100
+ - `memory_refs`: paths or nodes affected
101
+
102
+ Guidance:
103
+
104
+ - Use `context_graph` for reusable Brownfield findings, decisions, risks, invariants and exit criteria.
105
+ - Use `sot_registry` when source-of-truth ownership changes or drift is found.
106
+ - Use `scope_artifact` for run-specific evidence, ticket details, screenshots, logs or local reproduction data.
107
+ - Use `open_questions` when a durable question should survive the run but no answer is evidenced yet.
108
+ - Use `none` for one-off observations without future decision value.
109
+
110
+ ## Bug Lightweight Track
111
+
112
+ For narrow defect work, a repository may use a lightweight bug scope instead of the full UR/PRD/SD/TP chain when all of the following are true:
113
+
114
+ - the defect is tied to a concrete symptom or ticket
115
+ - the expected behavior is clear enough to test
116
+ - no new product semantics, architecture, policy, persistence or cross-owner decision is introduced
117
+ - a durable bug artefact or linked authoritative issue records reproduction, actual behavior, expected behavior, fix boundary, open questions and evidence plan
118
+
119
+ The Bug Lightweight Track does not remove QA, OR, evidence, Brownfield fit or exact approvals required by the target repository.
120
+ If the bug grows beyond the stated boundary, escalate to normal AGDF gate flow.
121
+
122
+ ## Domain Guardrail Packs
123
+
124
+ Repositories may define domain guardrail packs for recurring high-risk surfaces such as UI, persistence, integration, financial calculations, policy, security, migration or release operations.
125
+ A pack should define:
126
+
127
+ - trigger patterns
128
+ - required Brownfield touchpoints
129
+ - protected invariants
130
+ - required evidence
131
+ - review or QA escalation conditions
132
+
133
+ Domain guardrails are project-specific extensions.
134
+ They must not override AGDF gates, approvals or the Runtime Contract.
135
+
136
+ ## Support Answer Bridge
137
+
138
+ When the user asks about a concrete ticket, issue, incident or support question, end with exactly one smallest useful next step.
139
+ Do not treat that next step as approval.
140
+ When the next step is gated, name the required approval or AGDF skill instead of implying work may proceed.
141
+
30
142
  ## Chat Output Discipline
31
143
 
32
144
  Durable artefacts are for the repository, not for flooding the chat.
@@ -160,8 +272,25 @@ When a repository needs durable AGDF state, use the plugin-local `control/` scaf
160
272
  - `SOT_REGISTRY.md` prevents parallel sources of truth.
161
273
  - `CONTEXT_GRAPH.md` stores durable Brownfield findings, decisions, risks, evidence and exit criteria.
162
274
  - `AGENT_QUALITY_CONTRACTS.json` stores reusable block, revise and warning conditions.
275
+ - `memory_target`, `multi_scope_state` and branch/workspace evidence fields make ambiguity and persistence decisions visible without turning chat history into the source of truth.
163
276
  - OR reports live under `.agdf/control/artefacts/<key>/OR.md` when a run closeout is steering-relevant or should be auditable beyond the chat.
164
277
 
278
+ ### Human-readable Master Backlog
279
+
280
+ The Markdown backlog is a human steering view; CLI reports are its normalized
281
+ machine projection.
282
+
283
+ - Use readable status labels such as `In progress`, `Awaiting UAT` and
284
+ `Completed` in Markdown.
285
+ - Use links relative to `MASTER_BACKLOG.md`, such as
286
+ `[UR](artefacts/<key>/UR.md)`, instead of exposing long raw paths.
287
+ - Keep `Priority`, `Key`, `Work item`, `Status`, `Artefacts`, `Current spec`
288
+ and `Next step` visible for active and planned work.
289
+ - Keep one canonical template. Generated surface copies remain derived output.
290
+ - Normalize human labels and link targets only at the CLI parser boundary.
291
+ - Existing wide rows, raw paths and snake_case statuses remain supported for
292
+ backward compatibility.
293
+
165
294
  The scaffold is not a second documentation site. Link to authoritative artefacts instead of copying them.
166
295
 
167
296
  ## Agent-Native Runtime And CLI Verification
@@ -193,7 +322,10 @@ It must expose:
193
322
  - approved or active artefacts and approvals
194
323
  - `UR -> PRD -> SD -> TP -> QA_REPORT` relationships
195
324
  - evidence refs, missing evidence and declared risks
325
+ - multi-scope ambiguity and branch/workspace evidence limits when present
326
+ - memory persistence target, reason and references when present
196
327
  - Context Graph impact and gate effect
328
+ - the Run Status Card as a compact projection of current gate, next step and quality outlook
197
329
  - findings that explain why the delivery picture is `pass | warn | revise | block`
198
330
 
199
331
  Missing relationship evidence in the Artefact Chain is at least `revise` once the related gate artefact is approved or passed.
@@ -68,6 +68,10 @@ The CLI reports are validators and JSON evidence, not the primary user experienc
68
68
  13. After Brownfield Review, decide the process size before drafting PRD or implementing: `quick_task | structured_slice | structured_delivery | block`.
69
69
  14. The Mode/Slice Decision must be visible and evidenced before any Quick Task execution, PRD shortcut or implementation. A decision value without scope reason and evidence is still missing.
70
70
  15. Missing or incomplete control state must not push setup work back to the user. For a fresh request, draft the current minimal artefact in the response and request the exact approval. Initialize or write `.agdf/control/` only when durable control state is explicitly requested, already live for the repository, or required for a deterministic CLI/CI setup path. Implementation remains forbidden.
71
+ 16. Branch names, uncommitted diffs, generated summaries and chat history are not sufficient scope proof when durable artefacts or approvals are missing or conflicting.
72
+ 17. If multiple active scopes are plausible, list the evidenced competing lines and keep the current step at scope clarification or the earliest common safe gate.
73
+ 18. When maintaining `MASTER_BACKLOG.md`, use its canonical compact columns, readable status labels and document-relative Markdown links. Do not expose raw long paths or internal snake_case statuses in the human-facing table.
74
+ 19. Preserve legacy backlog compatibility through the CLI parser; do not create a second surface-specific backlog format.
71
75
 
72
76
  ## Gate Evaluation
73
77
 
@@ -100,6 +104,8 @@ Use what is available:
100
104
  - Brownfield Analysis status
101
105
  - CD+Tests, CR, QA, UAT status
102
106
  - signs of documentation/runtime/product-semantics drift
107
+ - branch/workspace evidence and whether it conflicts with durable artefacts
108
+ - competing active scopes or work lines
103
109
 
104
110
  If a status is not explicit, do not assume it is satisfied.
105
111
 
@@ -115,6 +121,7 @@ If a status is not explicit, do not assume it is satisfied.
115
121
  9. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
116
122
  10. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
117
123
  11. When `.agdf/control/` is missing or incomplete, make the next allowed artefact action explicit. For a fresh request, that means draft the minimal UR in the response, then request `Approval: UR`. Do not write a full control scaffold unless durable control state was explicitly requested or is already the repository's live AGDF working state.
124
+ 12. If branch, workspace and durable artefacts disagree, do not choose a scope silently; report the ambiguity and ask for the smallest clarifying gate action.
118
125
 
119
126
  ## Output
120
127
  Keep the result short and operational:
@@ -42,6 +42,8 @@ Use the Runtime Contract definition of `Relevant Run` to decide whether OR is ma
42
42
  8. Retained fallbacks require visible exit criteria and cleanup path.
43
43
  9. End with the immediately permissible next step.
44
44
  10. `CD+Tests` is not completion.
45
+ 11. When moving a backlog item to Completed or Superseded, use the canonical human-readable table and link the final OR with a document-relative Markdown link.
46
+ 12. Keep machine status normalization in the CLI; do not write internal snake_case status values into the human-facing backlog.
45
47
 
46
48
  ## When To Use
47
49
  - at the end of every relevant run
@@ -1,15 +1,19 @@
1
+ import { existsSync } from "node:fs";
2
+
1
3
  export const AGDFPlugin = async ({ directory, client }) => {
2
4
  const controlDir = `${directory}/.agdf/control`;
5
+ const hasRepositorySurface = () => existsSync(`${directory}/.opencode/AGDF.md`) && existsSync(`${directory}/.opencode/agents`);
3
6
 
4
7
  return {
5
8
  event: async ({ event }) => {
6
9
  if (event?.type === "session.created") {
10
+ const repositorySurface = hasRepositorySurface();
7
11
  await client.app.log({
8
12
  body: {
9
13
  service: "agdf",
10
14
  level: "info",
11
- message: "AGDF OpenCode surface active",
12
- extra: { controlDir },
15
+ message: repositorySurface ? "AGDF OpenCode surface active" : "AGDF OpenCode plugin loaded without repository surface",
16
+ extra: { controlDir, repositorySurface },
13
17
  },
14
18
  });
15
19
  }
@@ -20,6 +24,16 @@ export const AGDFPlugin = async ({ directory, client }) => {
20
24
  },
21
25
 
22
26
  "experimental.session.compacting": async (_input, output) => {
27
+ if (!hasRepositorySurface()) {
28
+ output.context.push([
29
+ "## AGDF Plugin Notice",
30
+ "The AGDF OpenCode npm plugin is loaded, but this repository does not contain the AGDF OpenCode surface.",
31
+ "Do not apply AGDF gates from the global plugin alone; repository instructions, subagents and control files are the source of truth.",
32
+ "Run `npx --yes @agdf/cli@latest opencode-repo` in this repository when AGDF governance should be active here.",
33
+ ].join("\n"));
34
+ return;
35
+ }
36
+
23
37
  output.context.push([
24
38
  "## AGDF Runtime Reminder",
25
39
  "Use `.opencode/AGDF.md`, `.opencode/agents/` and `.agdf/control/` as the AGDF source for this OpenCode session.",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-agdf",
3
- "version": "0.3.4",
3
+ "version": "0.4.0",
4
4
  "description": "Bootstrap AGDF repository-local plugin files, Copilot/OpenCode instructions, skills, control files and machine-readable checks.",
5
5
  "type": "module",
6
6
  "files": [