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.
- package/README.md +29 -11
- package/bin/create-agdf.js +546 -32
- package/generated/.agdf/control/templates/AGDF_RUN.md +29 -0
- package/generated/.agdf/control/templates/AGENT_QUALITY_CONTRACTS.json +48 -0
- package/generated/.agdf/control/templates/MASTER_BACKLOG.md +7 -10
- package/generated/.agdf/control/templates/artefacts/OR.md +20 -4
- package/generated/.github/skills/agdf-gate-check/SKILL.md +7 -0
- package/generated/.github/skills/agdf-release-or/SKILL.md +2 -0
- package/generated/.github/skills/agdf-runtime-contract.md +132 -0
- package/generated/.opencode/AGDF.md +8 -0
- package/generated/.opencode/README.md +4 -0
- package/generated/.opencode/agdf-runtime-contract.md +132 -0
- package/generated/.opencode/agents/agdf-brownfield-analysis.md +0 -5
- package/generated/.opencode/agents/agdf-clean-implementation-review.md +0 -5
- package/generated/.opencode/agents/agdf-code-review.md +0 -5
- package/generated/.opencode/agents/agdf-delivery-closeout.md +0 -5
- package/generated/.opencode/agents/agdf-gate-check.md +7 -5
- package/generated/.opencode/agents/agdf-qa-gate.md +0 -5
- package/generated/.opencode/agents/agdf-release-or.md +2 -5
- package/generated/.opencode/agents/agdf-task-plan-review.md +0 -5
- package/generated/AGENTS.md +4 -0
- package/generated/plugins/agdf/.codex-plugin/plugin.json +1 -1
- package/generated/plugins/agdf/control/templates/AGDF_RUN.md +29 -0
- package/generated/plugins/agdf/control/templates/AGENT_QUALITY_CONTRACTS.json +48 -0
- package/generated/plugins/agdf/control/templates/MASTER_BACKLOG.md +7 -10
- package/generated/plugins/agdf/control/templates/artefacts/OR.md +20 -4
- package/generated/plugins/agdf/meta/agdf-agent-router.md +4 -0
- package/generated/plugins/agdf/meta/agdf-plugin.definition.json +1 -1
- package/generated/plugins/agdf/meta/agdf-runtime-contract.md +132 -0
- package/generated/plugins/agdf/skills/gate-check/SKILL.md +7 -0
- package/generated/plugins/agdf/skills/release-or/SKILL.md +2 -0
- package/opencode-plugin.js +16 -2
- 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
|
package/generated/AGENTS.md
CHANGED
|
@@ -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:
|
|
@@ -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
|
|
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
|
-
|
|
|
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
|
-
|
|
|
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 |
|
|
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.
|
|
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
|
package/opencode-plugin.js
CHANGED
|
@@ -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