create-agdf 0.2.8 → 0.3.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 CHANGED
@@ -4,9 +4,23 @@ Bootstrap AGDF repository instructions and a machine-checkable control loop for
4
4
 
5
5
  ## Usage
6
6
 
7
+ Preferred long-term CLI shape:
8
+
9
+ ```bash
10
+ npx --yes agdf@latest codex
11
+ npx --yes agdf@latest opencode
12
+ npx --yes agdf@latest init
13
+ npx --yes agdf@latest config --language en
14
+ npx --yes agdf@latest doctor
15
+ npx --yes agdf@latest gate-check --json
16
+ ```
17
+
18
+ Backward-compatible scaffold usage:
19
+
7
20
  ```bash
8
21
  npm create agdf@latest -- codex
9
22
  npm create agdf@latest -- copilot
23
+ npm create agdf@latest -- opencode
10
24
  npm create agdf@latest -- both
11
25
  npm create agdf@latest -- init
12
26
  npm create agdf@latest -- config --language en
@@ -26,6 +40,7 @@ If no language is provided, `create-agdf` derives the preference from the local
26
40
 
27
41
  - `codex` writes a repository-local Codex marketplace under `.agents/plugins/` and a local AGDF plugin copy under `plugins/agdf/`
28
42
  - `copilot` writes `AGENTS.md`, Copilot custom instructions under `.github/`, visible repository skills under `.github/skills/`, and AGDF control templates under `.agdf/control/`
43
+ - `opencode` writes `opencode.json`, `.opencode/AGDF.md`, prefixed OpenCode agents under `.opencode/agents/`, explicit edit/bash permissions, and AGDF control templates under `.agdf/control/`
29
44
  - `both` writes the Codex repository-local marketplace plus the Copilot-facing repository files
30
45
  - `config` writes or updates only `.agdf/control/config.json` for an already installed plugin or an existing repository
31
46
 
@@ -35,6 +50,16 @@ Use the `codex` target when AGDF should be available only inside one repository
35
50
 
36
51
  After `npm create agdf@latest -- codex`, restart Codex in that repository, open `/plugins`, select `This repository` and install `agdf`.
37
52
 
53
+ Use the `opencode` target when AGDF should be available to OpenCode from repository files:
54
+
55
+ ```bash
56
+ npm create agdf@latest -- opencode
57
+ ```
58
+
59
+ OpenCode loads the AGDF npm plugin from `opencode.json`, AGENTS-style rules from `.opencode/AGDF.md`, explicit `edit`/`bash` permissions and the `agdf-` prefixed agents under `.opencode/agents/`.
60
+ If `opencode.json` already exists, AGDF keeps it unchanged and writes `opencode.agdf.json` as a merge fragment.
61
+ Using OpenCode's plugin installer for `create-agdf` can add the npm plugin entry, but AGDF still needs the repository instructions and agents. The `opencode` target writes the npm plugin entry and the repository files together.
62
+
38
63
  ## Control scaffold
39
64
 
40
65
  The generated `.agdf/control/templates/` files are reusable starting points for durable AGDF state:
@@ -124,6 +149,8 @@ The routing test installs `both` into a temporary target repository and checks t
124
149
 
125
150
  The repository publishes this package from `create-agdf/` via the GitHub Actions workflow `.github/workflows/publish-create-agdf.yml`.
126
151
 
152
+ The primary user-facing CLI package is published separately from `agdf/` and delegates to this package through the shared `create-agdf/cli` export.
153
+
127
154
  - Create or update the version in `create-agdf/package.json`
128
155
  - Push a matching git tag in the form `create-agdf-v<version>`
129
156
  - Ensure the repository secret `NPM_TOKEN` exists with publish rights for `create-agdf`
@@ -11,8 +11,9 @@ const generatedRoot = join(packageRoot, "generated");
11
11
  const pluginDefinitionPath = join(generatedRoot, "plugins", "agdf", "meta", "agdf-plugin.definition.json");
12
12
  const pluginDefinition = JSON.parse(readFileSync(pluginDefinitionPath, "utf8"));
13
13
  const pluginInstallCommand = "claude plugin add arndtgold/ai-native-governance-delivery-framework";
14
- const allowedTargets = new Set(["codex", "copilot", "both", "init", "config", "doctor", "gate-check", "delivery-map"]);
14
+ const allowedTargets = new Set(["codex", "copilot", "opencode", "both", "init", "config", "doctor", "gate-check", "delivery-map"]);
15
15
  const agdfFragmentPath = "AGENTS.agdf.md";
16
+ const openCodeConfigFragmentPath = "opencode.agdf.json";
16
17
  const userGateOrder = ["UR", "PRD", "SD", "TP", "QA", "UAT"];
17
18
  const durableGateArtefacts = new Set(["UR", "PRD", "SD", "TP", "QA"]);
18
19
  const internalStepArtefacts = new Set(["Brownfield Review"]);
@@ -25,6 +26,7 @@ const deliveryRelationships = [
25
26
  ];
26
27
  const codexSkillNames = pluginDefinition.skillSet.map((skill) => `${pluginDefinition.codex.skillPrefix}${skill.slug}`);
27
28
  const copilotSkillNames = pluginDefinition.skillSet.map((skill) => `${pluginDefinition.copilot.skillPrefix}${skill.slug}`);
29
+ const openCodeSkillNames = pluginDefinition.skillSet.map((skill) => `${pluginDefinition.opencode.skillPrefix}${skill.slug}`);
28
30
  const codexPluginFiles = [
29
31
  join(".agents", "plugins", "marketplace.json"),
30
32
  join("plugins", "agdf", ".codex-plugin", "plugin.json"),
@@ -112,13 +114,27 @@ const copilotSkillFiles = [
112
114
  join(".github", "skills", pluginDefinition.copilot.runtimeContractFileName),
113
115
  ...copilotSkillNames.map((skillName) => join(".github", "skills", skillName, "SKILL.md")),
114
116
  ];
117
+ const openCodeFiles = [
118
+ join(".opencode", pluginDefinition.opencode.instructionsFileName),
119
+ join(".opencode", "README.md"),
120
+ join(".opencode", pluginDefinition.opencode.runtimeContractFileName),
121
+ ...openCodeSkillNames.map((skillName) => join(".opencode", "agents", `${skillName}.md`)),
122
+ ];
115
123
 
116
124
  function printUsage() {
117
125
  console.log(`create-agdf
118
126
 
119
- Usage:
127
+ Preferred AGDF CLI:
128
+ npx --yes agdf@latest codex
129
+ npx --yes agdf@latest opencode
130
+ npx --yes agdf@latest init
131
+ npx --yes agdf@latest doctor
132
+ npx --yes agdf@latest gate-check --json
133
+
134
+ Scaffold-compatible npm create usage:
120
135
  npm create agdf@latest -- codex
121
136
  npm create agdf@latest -- copilot
137
+ npm create agdf@latest -- opencode
122
138
  npm create agdf@latest -- both
123
139
  npm create agdf@latest -- init
124
140
  npm create agdf@latest -- config --language de
@@ -126,6 +142,10 @@ Usage:
126
142
  npm create agdf@latest -- gate-check
127
143
  npm create agdf@latest -- delivery-map
128
144
 
145
+ Backward-compatible create-agdf usage:
146
+ npx --yes create-agdf@latest doctor --json
147
+ npx --yes create-agdf@latest gate-check --json
148
+
129
149
  Options:
130
150
  --dir <path> Write files into a specific directory
131
151
  --force Overwrite existing generated files
@@ -263,7 +283,7 @@ function parseArgs(argv) {
263
283
  }
264
284
 
265
285
  if (!target || !allowedTargets.has(target)) {
266
- console.error("Please choose one target: codex, copilot, both, init, config, doctor, gate-check or delivery-map.");
286
+ console.error("Please choose one target: codex, copilot, opencode, both, init, config, doctor, gate-check or delivery-map.");
267
287
  printUsage();
268
288
  process.exit(1);
269
289
  }
@@ -375,10 +395,33 @@ function generatedFilesForTarget(target, targetDir, force, languagePreference) {
375
395
  }
376
396
  }
377
397
 
398
+ if (target === "opencode") {
399
+ addLanguageConfig(files, languagePreference);
400
+ const openCodeConfigTargetPath = existsSync(join(targetDir, "opencode.json")) && !force ? openCodeConfigFragmentPath : "opencode.json";
401
+ files.push({
402
+ path: openCodeConfigTargetPath,
403
+ content: loadAsset("opencode.json"),
404
+ });
405
+
406
+ for (const openCodePath of openCodeFiles) {
407
+ files.push({
408
+ path: openCodePath,
409
+ content: loadAsset(openCodePath),
410
+ });
411
+ }
412
+
413
+ for (const controlPath of controlFiles) {
414
+ files.push({
415
+ path: controlPath,
416
+ content: loadAsset(controlPath),
417
+ });
418
+ }
419
+ }
420
+
378
421
  return files;
379
422
  }
380
423
 
381
- function printNextSteps(target, destination, files, wroteAgentsFragment) {
424
+ function printNextSteps(target, destination, files, wroteAgentsFragment, wroteOpenCodeConfigFragment) {
382
425
  console.log("");
383
426
  console.log(`AGDF bootstrap complete in ${destination}`);
384
427
  console.log("");
@@ -396,13 +439,13 @@ function printNextSteps(target, destination, files, wroteAgentsFragment) {
396
439
  }
397
440
  if (target === "init") {
398
441
  console.log("- Fill .agdf/control/AGDF_RUN.md with the current gate, evidence and next allowed action.");
399
- console.log("- Run npm create agdf@latest -- doctor to check the control state before the next agent run.");
442
+ console.log("- Run npx --yes agdf@latest doctor to check the control state before the next agent run.");
400
443
  console.log("- Commit the live control files once they represent the repository's current delivery state.");
401
444
  return;
402
445
  }
403
446
  if (target === "config") {
404
447
  console.log("- Restart or start a new agent session so the AGDF SessionStart hook reads the updated project language config.");
405
- console.log("- Run npm create agdf@latest -- doctor when this repository also uses durable AGDF control state.");
448
+ console.log("- Run npx --yes agdf@latest doctor when this repository also uses durable AGDF control state.");
406
449
  return;
407
450
  }
408
451
  if (wroteAgentsFragment) {
@@ -415,9 +458,18 @@ function printNextSteps(target, destination, files, wroteAgentsFragment) {
415
458
  if (target === "both") {
416
459
  console.log(`- Optional global Claude Code install: ${pluginInstallCommand}`);
417
460
  }
461
+ if (target === "opencode") {
462
+ if (wroteOpenCodeConfigFragment) {
463
+ console.log(`- Existing opencode.json detected. Merge ${openCodeConfigFragmentPath} into your current opencode.json so OpenCode loads .opencode/AGDF.md.`);
464
+ }
465
+ console.log(`- OpenCode will install the ${pluginDefinition.opencode.npmPackage} npm plugin from opencode.json at startup.`);
466
+ console.log("- Start OpenCode in this repository; it will load opencode.json, .opencode/AGDF.md and the AGDF subagents.");
467
+ console.log("- Use @agdf-gate-check for new build/change intent or unclear approval before later artefacts or implementation.");
468
+ console.log("- Run npx --yes agdf@latest init when the repository needs live AGDF control files.");
469
+ }
418
470
  if (target === "copilot" || target === "both") {
419
471
  console.log("- In GitHub Copilot CLI, run /instructions after the AGENTS.md step is complete to confirm that AGDF instructions and the repository skills are visible.");
420
- console.log("- Run npm create agdf@latest -- init when the repository needs live AGDF control files.");
472
+ console.log("- Run npx --yes agdf@latest init when the repository needs live AGDF control files.");
421
473
  }
422
474
  console.log("- Commit the generated files so the repository becomes the source of truth.");
423
475
  }
@@ -521,7 +573,7 @@ function evaluateDoctor(targetDir) {
521
573
  ? "Live control file is missing; only the template exists."
522
574
  : "Required live control file is missing.",
523
575
  relativePath,
524
- "Run npm create agdf@latest -- init only when the repository should own durable AGDF control state or deterministic setup is explicitly needed.",
576
+ "Run npx --yes agdf@latest init only when the repository should own durable AGDF control state or deterministic setup is explicitly needed.",
525
577
  );
526
578
  }
527
579
 
@@ -1136,7 +1188,7 @@ function evaluateGateCheck(targetDir) {
1136
1188
  allowed = [
1137
1189
  "draft the minimal UR for the requested change in the response",
1138
1190
  "request exact approval: Approval: UR",
1139
- "run npm create agdf@latest -- init only when durable control state or deterministic setup is explicitly needed",
1191
+ "run npx --yes agdf@latest init only when durable control state or deterministic setup is explicitly needed",
1140
1192
  ];
1141
1193
  forbidden = ["create PRD", "create SD", "create TP", "run Brownfield Analysis", "implement code", "claim QA or release readiness"];
1142
1194
  nextAllowedAction = "Draft the minimal UR for the request in the response, then ask for exact approval: Approval: UR. Do not write a full .agdf/control scaffold unless durable control state or deterministic setup is explicitly needed.";
@@ -1301,6 +1353,7 @@ function main() {
1301
1353
 
1302
1354
  const files = generatedFilesForTarget(options.target, options.dir, options.force, options.language);
1303
1355
  const wroteAgentsFragment = files.some(file => file.path === agdfFragmentPath);
1356
+ const wroteOpenCodeConfigFragment = files.some(file => file.path === openCodeConfigFragmentPath);
1304
1357
 
1305
1358
  try {
1306
1359
  for (const file of files) {
@@ -1311,7 +1364,7 @@ function main() {
1311
1364
  process.exit(1);
1312
1365
  }
1313
1366
 
1314
- printNextSteps(options.target, options.dir, files, wroteAgentsFragment);
1367
+ printNextSteps(options.target, options.dir, files, wroteAgentsFragment, wroteOpenCodeConfigFragment);
1315
1368
  }
1316
1369
 
1317
1370
  main();
@@ -49,21 +49,21 @@ Keep these files small and reviewable. They are control artefacts, not a second
49
49
  Create the live files with:
50
50
 
51
51
  ```bash
52
- npm create agdf@latest -- init
52
+ npx --yes agdf@latest init
53
53
  ```
54
54
 
55
55
  If only the project language preference is missing or should change after plugin installation, write just the config file:
56
56
 
57
57
  ```bash
58
- npm create agdf@latest -- config --language en
58
+ npx --yes agdf@latest config --language en
59
59
  ```
60
60
 
61
61
  Then check whether the live state is actionable:
62
62
 
63
63
  ```bash
64
- npm create agdf@latest -- doctor
65
- npx --yes create-agdf@latest doctor --json
66
- npx --yes create-agdf@latest gate-check --json
64
+ npx --yes agdf@latest doctor
65
+ npx --yes agdf@latest doctor --json
66
+ npx --yes agdf@latest gate-check --json
67
67
  ```
68
68
 
69
69
  `doctor` does not replace agent judgment. It catches basic control failures: missing live files, missing current gate, missing next allowed action, empty evidence, empty backlog pointer, empty source-of-truth registry, duplicate active SoT rows and invalid quality contracts.
@@ -41,10 +41,10 @@ Use `init` only when the user explicitly asks for durable AGDF control state, th
41
41
  Use the executable control path when a machine-readable check is requested, when the gate state is ambiguous, when CI or PR evidence is needed, or when a repository-local automation needs JSON output:
42
42
 
43
43
  ```bash
44
- npm create agdf@latest -- init
45
- npx --yes create-agdf@latest doctor --json
46
- npx --yes create-agdf@latest gate-check --json
47
- npx --yes create-agdf@latest delivery-map --json
44
+ npx --yes agdf@latest init
45
+ npx --yes agdf@latest doctor --json
46
+ npx --yes agdf@latest gate-check --json
47
+ npx --yes agdf@latest delivery-map --json
48
48
  ```
49
49
 
50
50
  `init` creates the control scaffold. `doctor` checks whether `.agdf/control/` is actionable. `agdf-gate-check` consumes that result and `AGDF_RUN.md` to report the operative process decision: `open | blocked`, current gate, blocking reason, missing approval, allowed outputs, forbidden outputs, next allowed action and evidence references.
@@ -0,0 +1,102 @@
1
+ # AGDF OpenCode instructions
2
+
3
+ ## Role
4
+ You are operating in an OpenCode project configured with AGDF.
5
+
6
+ Use the AGDF agents as workflow controls, not as documentation shortcuts.
7
+ Your goal is trustworthy progress: reduce uncertainty, establish evidence, preserve artefacts, verify outcomes and make the next allowed step explicit.
8
+
9
+ ## Surface Convention
10
+ OpenCode project agents do not have a plugin namespace.
11
+
12
+ Therefore generated OpenCode agent names use the AGDF prefix:
13
+
14
+ - `agdf-brownfield-analysis`
15
+ - `agdf-clean-implementation-review`
16
+ - `agdf-code-review`
17
+ - `agdf-delivery-closeout`
18
+ - `agdf-gate-check`
19
+ - `agdf-qa-gate`
20
+ - `agdf-release-or`
21
+ - `agdf-task-plan-review`
22
+
23
+ Do not remove that prefix in OpenCode-facing repository agents.
24
+ Codex and Claude Code plugin surfaces use unprefixed skill names because their plugin namespace already carries `agdf`.
25
+ ## Mode Selection
26
+ Default entry rule: a new user intent to build, add, change, extend, refactor or otherwise deliver something starts with `agdf-gate-check` unless it is clearly only a question, explanation, local inspection, or explicitly scoped review.
27
+
28
+ Use Quick Task Mode for questions, small reviews, local debugging and narrow fixes without new product semantics.
29
+
30
+ Use Structured Delivery Mode for new capabilities, architecture, policy, persistence, release-critical work, formal artefacts or explicit approvals.
31
+
32
+ Any new product semantics, functional change or user-visible behaviour change requires a durable UR first.
33
+ Persist it in `.agdf/control/` or link it from there to the target repository's authoritative source of truth before PRD, SD, TP, Brownfield Analysis or implementation.
34
+ Treat approval text and durable artefact presence as separate checks for UR, PRD, SD, TP and QA report decisions.
35
+ Do not infer approval from "ok", "go ahead", "do it", "approved", "continue", "leg los" or similar wording.
36
+ Those phrases may express intent to proceed, but they do not unlock a gate unless the exact gate formula is present.
37
+ After `Approval: UR`, run lightweight Brownfield Review before PRD when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible.
38
+ Brownfield Review must produce a Mode/Slice Decision: `quick_task`, `structured_slice`, `structured_delivery` or `block`.
39
+ 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
+ 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
+
42
+ Quick Task Mode must still use the Runtime Contract mini-output: `result`, `evidence`, `risk`, `next_step`.
43
+ Structured Delivery Mode must respect gates, reviews and closeout discipline.
44
+
45
+ ## Skill Routing
46
+ | Skill | Use For | Boundary |
47
+ |---|---|---|
48
+ | `agdf-brownfield-analysis` | after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems | clarifies reuse, owners, risks and Mode/Slice Decision; never bypasses gate-check; Brownfield Review is not implementation permission |
49
+ | `agdf-clean-implementation-review` | inspect workarounds, fallbacks, parallel structures or symptom fixes | not a TP or QA substitute |
50
+ | `agdf-code-review` | mandatory CR step after code changes, focused on defects, regression and security findings | does not replace TP review, clean review or QA |
51
+ | `agdf-delivery-closeout` | commit/PR-near handoff after QA/OR/UAT | never performs VCS actions automatically |
52
+ | `agdf-gate-check` | new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested | does not create later artefacts or skip Mode/Slice Decision after Brownfield Review |
53
+ | `agdf-qa-gate` | final QA decision | only instance for `pass | revise | block` |
54
+ | `agdf-release-or` | auditable closeout for every relevant run | not a QA substitute |
55
+ | `agdf-task-plan-review` | after implementation and before QA, verify TP coverage | no final QA decision |
56
+
57
+ Select exactly one primary skill first.
58
+ Add more only when they cover a distinct concrete risk dimension.
59
+ Do not choose `agdf-brownfield-analysis` as the first primary skill for a fresh "I want to build/change X" prompt unless `agdf-gate-check` or existing live AGDF control state already makes implementation preparation the next allowed action.
60
+ Never jump directly from `Approval: UR`, implicit consent, or a generic "start" request to implementation. Route to Brownfield Review, then a visible Mode/Slice Decision with evidence, then the smallest safe next gate or Quick Task execution.
61
+
62
+ ## Runtime Contract
63
+ For repeated output, gate, Quality Contract and Context Graph rules, use:
64
+
65
+ `agdf-runtime-contract.md`
66
+
67
+ Skills may include short reminders, but they must not carry a second complete rule or code table.
68
+
69
+ ## Durable Control State
70
+ When the target repository uses the AGDF control scaffold, keep live control files under `.agdf/control/`.
71
+ Use templates as starting points only.
72
+
73
+ Do not let chat history become the source of truth for gate state, approvals, evidence, backlog status or durable Brownfield knowledge.
74
+
75
+ 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
+ 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
+ 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.
78
+
79
+ ## Closeout
80
+ For Quick Task Mode, close with the Runtime Contract mini-output only:
81
+
82
+ - `result`
83
+ - `evidence`
84
+ - `risk`
85
+ - `next_step`
86
+
87
+ For relevant runs that change durable state, code, artefacts or gate status:
88
+
89
+ - run relevant checks or state the test gap
90
+ - never commit, push or open a PR automatically
91
+ - include exactly one `Next step:`
92
+ - include exactly one `Quality outlook:`
93
+
94
+
95
+ ## OpenCode Files
96
+
97
+ - OpenCode loads this file through `opencode.json` `instructions`.
98
+ - OpenCode agents live under `.opencode/agents/` and use the `agdf-` prefix.
99
+ - The AGDF OpenCode plugin is loaded from npm through `opencode.json` `plugin: ["create-agdf"]`.
100
+ - OpenCode permissions keep `edit` and `bash` on explicit approval by default.
101
+ - Shared output and gate rules live in `.opencode/agdf-runtime-contract.md`.
102
+ - Do not paste full control files, templates or artefact bodies into chat unless the user explicitly asks for the full content; summarize and link paths instead.
@@ -0,0 +1,19 @@
1
+ # AGDF OpenCode surface
2
+
3
+ These files were generated from the AGDF source repository for OpenCode.
4
+
5
+ - `opencode.json` loads the npm plugin `create-agdf` and `.opencode/AGDF.md` as repository instructions.
6
+ - `opencode.json` keeps `edit` and `bash` on `ask` so execution remains permissioned.
7
+ - `.opencode/agents/` contains AGDF subagents generated from the canonical AGDF skills.
8
+ - `.opencode/agdf-runtime-contract.md` is the shared gate and output contract.
9
+
10
+ ## Agents
11
+
12
+ - `agdf-brownfield-analysis`
13
+ - `agdf-clean-implementation-review`
14
+ - `agdf-code-review`
15
+ - `agdf-delivery-closeout`
16
+ - `agdf-gate-check`
17
+ - `agdf-qa-gate`
18
+ - `agdf-release-or`
19
+ - `agdf-task-plan-review`
@@ -0,0 +1,219 @@
1
+ # AGDF Runtime Contract
2
+
3
+ This contract centralizes recurring runtime rules for AGDF skills.
4
+ It is the operational reference for skill outputs, but it is not a second copy of the framework documentation.
5
+
6
+ ## Mode Selection
7
+
8
+ | Mode | Default | Escalate When |
9
+ |---|---|---|
10
+ | Quick Task Mode | small questions, reviews, debugging, local fixes without new product semantics | a new user capability, architecture/policy/persistence impact, formal artefacts, or approvals are involved |
11
+ | Structured Delivery Mode | formal delivery runs, gate-relevant work, release-critical changes | always use gate discipline, internal reviews, and OR |
12
+
13
+ Quick Task Mode must not become ritual gate overhead.
14
+ Structured Delivery must not bypass missing approvals.
15
+ New product semantics, functional change, user-visible behaviour, policy, persistence, architecture or release-critical work requires a durable UR in `.agdf/control/` or a linked authoritative repository SoT before later artefacts or implementation.
16
+ UR, PRD, SD, TP and QA report approvals require durable artefacts or linked authoritative repository SoT entries before the next gate can open.
17
+
18
+ ## Quick Task Output
19
+
20
+ Quick Tasks are intentionally lightweight, but they must not become invisible.
21
+ Use this compact output shape when no formal gate artefact is required:
22
+
23
+ - `result`: what changed or was concluded
24
+ - `evidence`: files, commands, observations, or reasoning that support the result
25
+ - `risk`: remaining risk or `none`
26
+ - `next_step`: the single next useful action or `none`
27
+
28
+ Do not add a separate `Quality outlook` line for pure Quick Tasks unless the task became a relevant run.
29
+
30
+ ## Chat Output Discipline
31
+
32
+ Durable artefacts are for the repository, not for flooding the chat.
33
+ When a skill creates or updates `.agdf/control/` files, gate artefacts, reviews, QA reports or OR reports, the chat response must stay compact:
34
+
35
+ - name the artefact path and status
36
+ - summarize the decision or content in a few lines
37
+ - state the current gate, forbidden work and next permissible step
38
+ - mention validation evidence when available
39
+
40
+ Do not paste full control files, full artefact bodies, full templates or full generated reports into the chat unless the user explicitly asks to see the full content.
41
+ For larger or more formal work, create or update the durable artefacts fully, then reference them by path and summarize what changed.
42
+
43
+ ## Relevant Run
44
+
45
+ A relevant run is any run that changes durable state, creates or updates an AGDF artefact, changes code or runtime behaviour, performs a gate decision, blocks on a governance condition, produces QA/UAT/release evidence, or closes a delivery slice.
46
+
47
+ OR is not mandatory for a pure explanation, read-only inspection, small review, or local debugging step that produces no durable state change and no gate consequence.
48
+ When in doubt, use a short OR-lite only if it clarifies gate state, evidence, risk, or the next permissible step.
49
+
50
+ ## Gate Rules
51
+
52
+ - User gates: `UR -> PRD -> SD -> TP -> QA -> UAT`
53
+ - Internal mandatory steps: `Brownfield Review -> Mode/Slice Decision -> Brownfield Analysis -> CD+Tests -> CR -> OR`
54
+ - Exact approval formula: `Approval: <GateName>`
55
+ - Legacy alias: `Freigabe: <GateName>` may be accepted when reviewing older German runs, but all new outputs must use `Approval: <GateName>`.
56
+ - Implicit consent is not approval. Phrases such as "ok", "go ahead", "do it", "approved", "continue", "leg los" or "looks good" are work intent, not gate approval.
57
+ - The earliest blocking gate wins.
58
+ - For UR, PRD, SD, TP and QA, approval and durable artefact presence are separate requirements. A gate is not satisfied by approval text alone when its artefact is missing from `.agdf/control/` or not linked to the authoritative repository SoT.
59
+ - Approval of one user gate permits work on the next allowed gate artefact or required internal step only. It does not permit implementation unless the approved gate is `TP` and required internal implementation prerequisites are satisfied.
60
+ - Gates must never be skipped or inferred from urgency, tone, chat history, task wording or an instruction to "start". The next allowed action is always the next unsatisfied gate or internal mandatory step.
61
+ - Missing control files or missing current-state fields do not forbid the agent from preparing the current allowed artefact. They forbid later-gate work and implementation. For a fresh request, the default allowed work is to draft a minimal UR in the response and request `Approval: UR`. Initialize or write `.agdf/control/` only when the user explicitly asks for durable AGDF control state, the repository already uses `.agdf/control/` as its live working state, or a deterministic CLI/CI setup path is being executed.
62
+ - `Approval: UR` permits Brownfield Review after G-00 first, then a Mode/Slice Decision. It never permits implementation by itself.
63
+ - PRD, SD and TP depth is chosen after Brownfield Review through the Mode/Slice Decision, not before existing-system impact is understood.
64
+ - The Mode/Slice Decision must be visible before any PRD shortcut, Quick Task execution or implementation: record the decision, required next gate, scope reason and evidence in `AGDF_RUN.md` or an equivalent linked control artefact.
65
+ - `Approval: PRD` permits Solution Design drafting, not implementation.
66
+ - `Approval: SD` permits Task/Test Plan drafting, not implementation.
67
+ - `Approval: TP` permits implementation-preparation Brownfield Analysis and then CD+Tests when Brownfield evidence supports it.
68
+ - `CD+Tests` is implementation and test status only, not a delivery signal.
69
+ - `agdf-code-review` standardizes the mandatory `CR` step, but does not replace QA.
70
+ - `agdf-qa-gate` decides final `pass | revise | block`.
71
+ - `agdf-release-or` reports the run, but does not replace QA or produce the operative commit/PR handoff.
72
+ - `agdf-delivery-closeout` owns the operative Git handoff text when QA/OR/UAT state allows it.
73
+
74
+ ## Brownfield Review After G-00
75
+
76
+ After an approved and durable UR, perform a lightweight `Brownfield Review` before PRD when Brownfield, UI, UX, admin, runtime, policy, persistence, architecture, ownership or source-of-truth impact is possible.
77
+
78
+ This review is not a new user approval gate, not PRD, not SD, not TP and not implementation permission.
79
+ It is the sizing and routing step that decides how much later gate discipline is actually needed.
80
+
81
+ Its output is limited to:
82
+
83
+ - workstream or follow-up-slice classification
84
+ - `Mode/Slice Decision`: `quick_task | structured_slice | structured_delivery | block`
85
+ - affected existing owners, source-of-truth artefacts, contracts, policies, runtime paths or tests
86
+ - reuse-before-create risks and parallel-structure risks
87
+ - open questions that PRD or SD must resolve
88
+ - whether implementation-preparation Brownfield Analysis will also be needed after TP
89
+
90
+ Mode/Slice Decision rules:
91
+
92
+ - `quick_task`: use only when Brownfield Review shows a narrow local change, no new product semantics beyond the approved UR, no architecture/policy/persistence/contract expansion, and evidence is sufficient to proceed with a small implementation plus relevant checks.
93
+ - `structured_slice`: use when some formal artefacts are needed, but they can stay intentionally small and scoped to the approved slice.
94
+ - `structured_delivery`: use when the change has broad product, architecture, runtime, policy, persistence, release or cross-owner impact.
95
+ - `block`: use when ownership, SoT, impact, evidence or product direction is not clear enough to choose a safe path.
96
+
97
+ A Mode/Slice Decision without scope reason and evidence is not recorded. Treat it as missing and keep the next step at `Mode/Slice Decision`.
98
+
99
+ ## Gate Transition Model
100
+
101
+ This table is the canonical transition model. Skills may reference it, but must not carry a second complete copy.
102
+
103
+ | State | Current gate or step | Allowed | Forbidden | Missing approval |
104
+ |---|---|---|---|---|
105
+ | No approved UR | `UR` | clarify user need, formulate and persist UR, request `Approval: UR` | PRD, SD, TP, Brownfield Analysis, implementation, QA, release | `Approval: UR` |
106
+ | `UR` approved and UR artefact persisted or linked, Brownfield Review missing | `Brownfield Review` | classify workstream, existing owners, SoT, reuse risks, change size and PRD/SD open questions; mark review done or not_applicable | PRD, SD, TP, implementation, QA, release | none |
107
+ | Brownfield Review done or not_applicable, Mode/Slice Decision missing or incomplete | `Mode/Slice Decision` | decide `quick_task`, `structured_slice`, `structured_delivery` or `block`; record scope reason, evidence and required next gate depth | PRD, SD, TP, implementation, QA, release | none |
108
+ | Mode/Slice Decision is `quick_task` | `Quick Task Execution` | implement only the narrow approved UR scope, run relevant checks, record evidence and OR-lite when the run is relevant | broad PRD/SD/TP by ritual, scope expansion, QA or release claims without evidence | none |
109
+ | Mode/Slice Decision is `structured_slice` or `structured_delivery`, PRD missing or draft | `PRD` | draft/refine PRD at the smallest justified depth, define scope, acceptance criteria and non-goals, persist/link PRD, request `Approval: PRD` | SD, TP, implementation-preparation Brownfield Analysis, implementation, QA, release | `Approval: PRD` |
110
+ | `PRD` approved and PRD artefact persisted or linked, SD missing or draft | `SD` | draft/refine Solution Design, ownership and architecture, persist/link SD, request `Approval: SD` | TP, implementation, QA, release | `Approval: SD` |
111
+ | `SD` approved and SD artefact persisted or linked, TP missing or draft | `TP` | draft/refine Task/Test Plan, task IDs, evidence plan, persist/link TP, request `Approval: TP` | implementation, QA, release | `Approval: TP` |
112
+ | `TP` approved and TP artefact persisted or linked, Brownfield Analysis missing | `Brownfield Analysis` | run Brownfield Analysis for approved TP scope | implementation, QA, release | none |
113
+ | Brownfield Analysis passed for approved TP | `CD+Tests` | implement approved TP tasks and run tests | QA pass, UAT, release | none |
114
+ | `QA` approved but QA report missing or not pass | `QA` | persist/link QA report with `pass` decision or revise/block evidence | UAT, release | none |
115
+
116
+ ## Brownfield Modes
117
+
118
+ The `agdf-brownfield-analysis` skill has two explicit modes:
119
+
120
+ - `post_ur_review`: lightweight sizing and routing after approved durable UR; decides Mode/Slice Decision before PRD depth or implementation is chosen.
121
+ - `pre_implementation_analysis`: implementation-preparation analysis after approved durable TP; verifies reuse path, owners, regression risk and fit before `CD+Tests`.
122
+
123
+ Do not mix the modes silently. Name the active mode in Brownfield output.
124
+
125
+ ## Quality Contract Output
126
+
127
+ Structured Delivery skills use this shape when relevant:
128
+
129
+ - `decision`: `pass | revise | block | not_applicable`
130
+ - `evidence`: concrete artefacts, files, tests, logs, diffs, or observations
131
+ - `missing_evidence`: missing proof needed for a stronger claim
132
+ - `risks`: remaining risks, assumptions, fallbacks, drift, or blockers
133
+ - `required_next_step`: exactly the next clean step
134
+ - `impact_codes`: affected Quality Contract codes, if the target repo has a registry
135
+
136
+ A skill may briefly remind this shape, but must not duplicate a complete code or rule matrix.
137
+
138
+ ## Context Graph Output
139
+
140
+ When a run affects project memory or a Context Graph, use:
141
+
142
+ - `Situation:` short plain-language summary when the impact is non-trivial
143
+ - `context_graph_impact`: `none | link_only | update_existing_node | new_node_required | sot_drift`
144
+ - `context_graph_refs`
145
+ - `context_graph_required_action`: `none | link | update | create | resolve_drift`
146
+ - `context_graph_gate_effect`: `none | warning | revise | block`
147
+ - `context_graph_evidence`
148
+
149
+ Do not create a new node for a mere version, a general chat summary, or a local observation without a concrete next clean step.
150
+ `sot_drift` must not pass silently as a warning.
151
+
152
+ ## Control Scaffold
153
+
154
+ When a repository needs durable AGDF state, use the plugin-local `control/` scaffold as the starting point.
155
+
156
+ - `config.json` stores project language preferences. Use `artifact_language` for generated AGDF artefacts and `chat_language` for user-facing responses unless the user explicitly asks otherwise. Runtime rules remain English.
157
+ - `AGDF_RUN.md` is the current run dashboard.
158
+ - `MASTER_BACKLOG.md` is the living pointer for active delivery work.
159
+ - `BROWNFIELD_REVIEW.md` records the post-UR existing-system view and Mode/Slice Decision before PRD depth or Quick Task execution is chosen.
160
+ - `SOT_REGISTRY.md` prevents parallel sources of truth.
161
+ - `CONTEXT_GRAPH.md` stores durable Brownfield findings, decisions, risks, evidence and exit criteria.
162
+ - `AGENT_QUALITY_CONTRACTS.json` stores reusable block, revise and warning conditions.
163
+ - 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
+
165
+ The scaffold is not a second documentation site. Link to authoritative artefacts instead of copying them.
166
+
167
+ ## Agent-Native Runtime And CLI Verification
168
+
169
+ AGDF is agent-native first and CLI-verifiable by design.
170
+
171
+ The primary operating path is the active skill plus the live `.agdf/control/` artefacts.
172
+ Agents should read the repository state, apply this Runtime Contract, create or update only the currently allowed artefact, and make the next permissible step explicit.
173
+ When control state is missing for a fresh request, keep the first step lightweight: draft the minimal UR in the response and request `Approval: UR`.
174
+ Initialize a control scaffold only when durable AGDF control state is explicitly requested, already used by the repository, or required by a deterministic CLI/CI setup path.
175
+
176
+ Helper commands are deterministic proof and automation interfaces, not the normal-work ritual:
177
+
178
+ - `init` creates the machine-readable control scaffold.
179
+ - `doctor --json` checks whether `.agdf/control/` is consistent and actionable; it is not the reviewer.
180
+ - `gate-check --json` reports reproducible gate state; it does not replace the gate-check skill judgement.
181
+ - `delivery-map --json` reports the delivery picture for CI, PRs, regression checks and audit trails.
182
+
183
+ Machine-readable outputs should stay agent-friendly: stable decisions, blocking gate or current gate, missing approval, allowed outputs, forbidden outputs, next step, evidence and findings.
184
+ They make the repository state checkable, but they do not replace the native skill workflow or the durable control artefacts.
185
+
186
+ ## Delivery Map
187
+
188
+ `delivery-map --json` is the machine-readable delivery picture for the active control state.
189
+ It derives, but does not replace, the live `.agdf/control/AGDF_RUN.md` and `MASTER_BACKLOG.md` state.
190
+
191
+ It must expose:
192
+
193
+ - approved or active artefacts and approvals
194
+ - `UR -> PRD -> SD -> TP -> QA_REPORT` relationships
195
+ - evidence refs, missing evidence and declared risks
196
+ - Context Graph impact and gate effect
197
+ - findings that explain why the delivery picture is `pass | warn | revise | block`
198
+
199
+ Missing relationship evidence in the Artefact Chain is at least `revise` once the related gate artefact is approved or passed.
200
+ Declared missing evidence, declared risk or Context Graph gate effect may escalate the delivery map to `warn`, `revise` or `block`.
201
+
202
+ ## Skill Output
203
+
204
+ Every skill output should be as short as possible and as concrete as needed.
205
+ It must distinguish:
206
+
207
+ - facts
208
+ - evidence
209
+ - assumptions
210
+ - interpretations
211
+ - missing evidence
212
+ - the next permissible step
213
+
214
+ ## Do Not Duplicate
215
+
216
+ The explanatory framework lives in `docs/`.
217
+ The operating philosophy lives in `plugin/meta/agdf-constitution.md`.
218
+ The principles live in `plugin/meta/agdf-tenets.md`.
219
+ This contract is only the compact runtime interface for skills.