create-agdf 0.2.8 → 0.3.0

package/generated/.opencode/agents/agdf-brownfield-analysis.md

@@ -0,0 +1,142 @@
+---
+description: after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems
+mode: subagent
+---
+
+---
+name: agdf-brownfield-analysis
+description: Use this skill after gate-check or live AGDF control state confirms that Brownfield Review or implementation preparation is allowed. Use it after Approval: UR as the lightweight Brownfield Review after G-00 before PRD when existing systems may be affected, and again before non-trivial implementation after TP. Do not use it as the first AGDF skill for a fresh "I want to build/change X" prompt when approval, scope, or next allowed action is unclear.
+---
+
+# brownfield-analysis
+
+## Purpose
+Ensure delivery in an existing system is Brownfield-oriented, not Greenfield-style.
+
+The skill answers:
+
+- which existing artefacts matter
+- what already exists fully or partially
+- what can be reused, extended, or refactored
+- whether new artefacts are really needed
+- architecture, compatibility, migration, and regression impact
+- the minimal clean next step
+- whether Context Graph impact exists without automatically creating a node
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+Brownfield-specific output must make evidence, missing existing-system view, parallel-structure risk, reuse strategy, and the minimal next step visible.
+When `.agdf/control/` is present, persist or link `post_ur_review` output under `.agdf/control/artefacts/<key>/BROWNFIELD_REVIEW.md`.
+
+## Modes
+
+- `post_ur_review`: use after approved durable UR to size and route the work. Output must decide `quick_task`, `structured_slice`, `structured_delivery`, or `block` with scope reason and evidence.
+- `pre_implementation_analysis`: use after approved durable TP to verify the implementation path before `CD+Tests`. Output must focus on reuse path, owners, regression risk, test impact and minimal clean implementation.
+
+Do not mix both modes silently. Name the active mode in the output.
+
+## Rules
+1. Brownfield first: understand the existing codebase before PRD/SD decisions when existing-system impact is possible, and again before implementation.
+2. Brownfield Review after `Approval: UR` is a sizing and routing step. It must visibly decide `quick_task`, `structured_slice`, `structured_delivery`, or `block` before PRD depth or implementation is chosen.
+3. Reuse-before-create: prefer existing modules, services, components, tables, endpoints, tests, and configuration.
+4. Minimal clean slice: choose the smallest durable intervention, not merely the smallest technical diff.
+5. No silent parallel structures.
+6. Existing architecture, naming, error handling, logging, security, and test conventions are binding unless deviation is justified.
+7. What is not visibly evidenced does not count as existing.
+8. Async execute paths must not become a second product-policy decision point.
+9. Visible state ownership must be checked for chat, rendering, scrolling, recovery, and status problems.
+10. SoT/runtime/product-semantics drift must be named; if official behaviour must be decided first, recommend UR or equivalent product direction.
+11. Large UI surfaces and state hooks must be checked for mixed render, view-model, derived state, orchestration, persistence, and recovery ownership.
+12. Context Graph impact must be curated; it is not a review log or version index.
+13. Specification archive migrations must follow the archive index if present.
+
+## When To Use
+- after `agdf-gate-check` permits `Brownfield Review` or live `.agdf/control/AGDF_RUN.md` names Brownfield Review as the next allowed action
+- after `agdf-gate-check` permits implementation preparation or live `.agdf/control/AGDF_RUN.md` already names Brownfield Analysis as the next allowed action
+- after `Approval: UR` when existing owners, SoT, contracts, policies, persistence, runtime paths, tests, UI, UX or architecture may affect PRD/SD scope
+- before `CD+Tests`
+- before changes to an existing repository
+- bug fixes in existing modules
+- feature extensions in existing architecture
+- refactorings
+- unclear existing coverage
+- risk of new parallel structures
+- a TP is clear but its connection to the existing system is not
+
+## Inputs
+Use what is available:
+
+- approved UR, Task Plan, `task_id`, `story_id`
+- project structure
+- affected files, modules, services, APIs, data models
+- existing tests
+- architecture notes from PRD or SD
+- repository conventions
+
+If inputs are missing, work only from observable evidence and mark gaps explicitly.
+If gate status, approval, scope or next allowed action is unclear, stop and route to `agdf-gate-check` instead of recommending PRD/SD detail or starting implementation.
+When used as Brownfield Review after `Approval: UR`, do not recommend PRD, SD, TP, or implementation until the Mode/Slice Decision is explicit, evidenced and recorded.
+
+## Workflow
+1. Identify affected tasks and scope.
+2. Find relevant existing artefacts.
+3. Assess current coverage before new implementation:
+   - `fully_done`
+   - `partially_done`
+   - `not_done`
+4. Choose reuse strategy:
+   - `extend`
+   - `refactor`
+   - `replace`
+   - `new`
+5. Assess change impact:
+   - files/modules
+   - interfaces
+   - data model/migrations
+   - backwards compatibility
+   - regression tests
+   - side effects
+6. Check parallel-structure risk.
+7. Check SoT/runtime/product-semantics drift.
+8. Check primary visible ownership for UI/status/recovery paths.
+9. Check UI monolith risk for large surfaces or central hooks.
+10. Check Context Graph impact according to `../agdf-runtime-contract.md`.
+11. Recommend the minimal clean implementation path.
+
+## Output
+Use a concise structure:
+
+```text
+## Brownfield Analysis
+- mode: post_ur_review | pre_implementation_analysis
+- decision: pass | revise | block | not_applicable
+- mode_slice_decision: quick_task | structured_slice | structured_delivery | block
+- required_next_gate: none | PRD | SD | TP | Brownfield Analysis
+- artefact: .agdf/control/artefacts/<key>/BROWNFIELD_REVIEW.md | none
+- scope:
+- evidence:
+- transparency: why later artefacts are skipped, shortened or required
+- missing_evidence:
+- current_coverage:
+- reuse_strategy:
+- risks:
+- context_graph_impact:
+- required_next_step:
+```
+
+## Pass / Revise / Block Guidance
+- `pass`: existing owners are understood, reuse path is clear, and no blocking drift or parallel structure risk remains.
+- `revise`: relevant evidence, tests, ownership, or reuse path is incomplete.
+- `block`: implementation would create a second SoT, second owner, unresolved product semantics, or hard unmitigated risk.
+
+## Forbidden
+This skill must not:
+
+- propose a Greenfield replacement without evidence
+- silently accept overlapping ownership
+- convert product-semantics drift into a mere refactor
+- create Context Graph nodes automatically
+- treat archive links as active current specification signals
+- recommend broad PRD/SD/TP or implementation by reflex before Mode/Slice Decision is recorded
+

package/generated/.opencode/agents/agdf-clean-implementation-review.md

@@ -0,0 +1,106 @@
+---
+description: inspect workarounds, fallbacks, parallel structures or symptom fixes
+mode: subagent
+---
+
+---
+name: agdf-clean-implementation-review
+description: Use this skill to determine whether an implementation is a clean primary solution or whether fallbacks, workarounds, guards, defaults, shims, or parallel structures have made it unnecessarily complex. Use it after code changes, before QA, or whenever symptom treatment is suspected.
+---
+
+# clean-implementation-review
+
+## Purpose
+Evaluate implementation integrity.
+
+This skill answers:
+
+- was the task solved with a clean primary solution
+- was the root cause fixed or only masked
+- were unnecessary fallbacks, workarounds, guards, defaults, or shims introduced
+- were unnecessary parallel structures introduced
+- does the solution fit the existing architecture
+- is it maintainable or workaround-heavy
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+Clean-review-specific output must make the primary solution, fallbacks, workarounds, parallel structures, exit criteria, and next cleanup/review step visible.
+
+## Rules
+1. Clean primary solution before fallback.
+2. Root cause before symptom masking.
+3. Fallbacks are exceptions, not target architecture.
+4. Every retained fallback needs rationale, target state, and exit condition.
+5. No silent parallel structures.
+6. Brownfield fit is mandatory.
+7. Maintainability matters; "works somehow" is not enough.
+8. Async execute paths must not decide product rules again.
+9. Shared finalization or merge rules belong in one owner.
+
+## When To Use
+- after `CD+Tests`
+- before QA
+- when a solution contains many guards, defaults, or special paths
+- when wrappers or helper layers were introduced
+- when symptom treatment is suspected
+- when fallback, retry, or compatibility-shim logic was added
+- when code works but the architecture looks questionable
+
+## Inputs
+Use what is available:
+
+- Task Plan
+- Code Deliverables
+- changed files
+- tests and test results
+- `agdf-code-review` or Code Review Report
+- QA Report
+- Brownfield Analysis findings
+- PRD or SD architecture notes
+
+If evidence is missing, mark it explicitly.
+
+## Workflow
+1. Understand the intended change.
+2. Identify the primary implementation path.
+3. Identify fallbacks, guards, defaults, shims, retries, wrappers, and catch-all branches.
+4. Decide whether each is justified.
+5. Check for parallel ownership.
+6. Check Brownfield fit.
+7. Assess whether the implementation fixes the root cause.
+8. Assign a decision:
+   - `pass`
+   - `revise`
+   - `block`
+   - `not_applicable`
+
+## Output
+Use this compact structure:
+
+```text
+## Clean Implementation Review
+- decision:
+- primary_solution:
+- evidence:
+- fallbacks_retained:
+- workaround_or_shim_risk:
+- parallel_structure_risk:
+- brownfield_fit:
+- missing_evidence:
+- required_next_step:
+```
+
+## Pass / Revise / Block Guidance
+- `pass`: primary solution is clean, tested, and integrated with existing owners.
+- `revise`: solution works but contains avoidable fallback, unclear ownership, or missing evidence.
+- `block`: solution creates a second SoT, a second owner, unbounded fallback, or masks unresolved product semantics.
+
+## Forbidden
+This skill must not:
+
+- accept fallback-heavy logic as target architecture
+- hide unjustified workarounds
+- treat green tests as proof of solution integrity
+- decide final QA
+

package/generated/.opencode/agents/agdf-code-review.md

@@ -0,0 +1,100 @@
+---
+description: mandatory CR step after code changes, focused on defects, regression and security findings
+mode: subagent
+---
+
+---
+name: agdf-code-review
+description: Use this skill after code changes and before QA to produce the mandatory Code Review Report for correctness, regression, security, and maintainability findings in the actual diff. It standardizes the CR step without replacing TP review, clean review, or QA.
+---
+
+# code-review
+
+## Purpose
+Produce the mandatory Code Review Report (CR) for a relevant run.
+
+It answers:
+
+- whether the changed code shows functional defects, security issues, regression risks, or maintainability problems that matter
+- whether findings are blocking, revisable, or advisory
+- which concrete evidence in files, diffs, tests, or runtime observations supports each finding
+- which issues must be fixed before QA
+- whether Brownfield, TP, or clean-review follow-up remains open
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for Quality Contract output, Context Graph fields, gate terms, and non-duplication rules.
+
+Code-review-specific output must make actual findings, missing review scope, evidence strength, and the next required step visible.
+
+## Rules
+1. Review the actual diff and impacted code, not intent alone.
+2. Findings require concrete evidence.
+3. Prioritize correctness, safety, data integrity, compatibility, and maintainability over style.
+4. Do not generate style-only noise.
+5. Missing review scope or evidence must stay visible.
+6. Brownfield owners and existing conventions are binding unless deviation is justified.
+7. Distinguish blocking defects from fixable review findings.
+8. CR does not grant QA pass.
+
+## When To Use
+- after `CD+Tests`
+- before `QA`
+- when code changes exist
+- when multiple agents or contributors touched the same area
+- when a commit-near change needs explicit review evidence
+
+## Inputs
+Use what is available:
+
+- changed files and diff
+- affected neighbouring code
+- test/build results
+- Brownfield Analysis
+- Task Plan and TP Review
+- Clean Implementation Review
+- runtime or UI evidence
+- known risks or follow-up decisions
+
+If no code changes are present, do not invent a CR result.
+
+## Workflow
+1. Inspect the changed files and directly impacted neighbours.
+2. Check correctness, edge cases, and error paths.
+3. Check security, data handling, and state ownership risks.
+4. Check regression and compatibility risks.
+5. Check maintainability only where it creates real defect or change-risk exposure.
+6. Classify the overall result:
+   - `pass`
+   - `revise`
+   - `block`
+   - `not_applicable`
+7. Set exactly one required next step.
+
+## Output
+Use this compact structure:
+
+```text
+## Code Review
+- decision: pass | revise | block | not_applicable
+- findings:
+  - [severity] file/path - issue - evidence
+- missing_evidence:
+- risks:
+- required_next_step:
+```
+
+## Decision Guidance
+- `pass`: no meaningful review finding remains evident in reviewed scope.
+- `revise`: fixable correctness, regression, or maintainability issues remain.
+- `block`: a hard defect, security risk, data-integrity risk, or unresolved critical uncertainty remains.
+- `not_applicable`: no code changes were present for review.
+
+## Forbidden
+This skill must not:
+
+- decide final QA
+- accept a green build as sufficient review evidence
+- hide missing review scope
+- generate style-only findings
+- duplicate TP Review or QA as if they were the same step
+

package/generated/.opencode/agents/agdf-delivery-closeout.md

@@ -0,0 +1,115 @@
+---
+description: commit/PR-near handoff after QA/OR/UAT
+mode: subagent
+---
+
+---
+name: agdf-delivery-closeout
+description: Use this skill for the final delivery handoff after QA, OR, or UAT when a run should move toward commit, push, or PR. It standardizes commit-ready summaries, UAT-gated commit offers, and the next delivery step without replacing QA or OR decisions.
+---
+
+# delivery-closeout
+
+## Purpose
+Standardize the operational delivery closeout.
+
+It answers:
+
+- what operational delivery status applies after QA, OR, or UAT
+- whether a commit-ready Git summary should be provided
+- whether a commit should be actively offered after `Approval: UAT`
+- which next delivery step makes sense: commit, push, PR, rollout, or none
+- whether evidence-based technical follow-up remains useful
+- whether Context Graph follow-up from OR/QA remains open
+
+This skill does not replace `agdf-qa-gate`, `agdf-release-or`, user approvals, or gate decisions.
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for closeout discipline, gate terms, Context Graph fields, and non-duplication rules.
+
+## Rules
+1. Delivery follows gate clarity.
+2. Never perform commit, push, or PR automatically.
+3. Use one handoff format:
+   - `Commit title`
+   - `Commit body`
+   - optional `Migration/Rollout note`
+4. `Approval: UAT` unlocks an active commit offer when code changes exist.
+5. No commit handoff for runs without code changes.
+6. Always include exactly one next step and one quality outlook.
+
+## When To Use
+- after `QA pass` with code changes
+- after OR when delivery handoff should be clean
+- after `Approval: UAT`
+- when the user asks for commit, push, or PR handoff
+
+Do not use as a substitute for `agdf-qa-gate`, `agdf-release-or`, or `agdf-gate-check`.
+
+## Inputs
+Use what is available:
+
+- QA Report
+- OR
+- current gate status
+- whether code changes exist
+- existing commit-ready summary
+- rollout or migration notes
+- open technical risks or documentation gaps
+- Context Graph impact from OR/QA/review
+
+If code-change status is unclear, do not claim a commit handoff.
+
+## Workflow
+1. Classify the closeout:
+   - `qa_pass_with_code`
+   - `qa_pass_without_code`
+   - `uat_approved_with_code`
+   - `uat_approved_without_code`
+   - `non_delivery_closeout`
+2. Derive Git handoff only when code changes exist.
+3. Set exactly one next delivery step:
+   - offer commit
+   - offer push
+   - offer PR
+   - no further delivery step
+   - run QA/review
+   - obtain UAT/approval
+   - perform documentation follow-up
+4. Set quality outlook:
+   - no further technical follow-up
+   - more tests
+   - refactoring
+   - documentation sharpening
+   - monitoring/runtime verification
+5. If `Approval: UAT` exists and code changes were delivered, actively offer the commit but do not run it.
+
+## Output
+For code-changing runs:
+
+```text
+Delivery status:
+Next step:
+Quality outlook:
+Commit title:
+Commit body:
+Migration/Rollout note:
+```
+
+For non-code runs:
+
+```text
+Delivery status:
+Next step:
+Quality outlook:
+```
+
+## Forbidden
+This skill must not:
+
+- decide QA pass
+- replace OR
+- execute commit, push, or PR
+- invent a commit handoff for non-code runs
+- imply new gate approvals
+

package/generated/.opencode/agents/agdf-gate-check.md

@@ -0,0 +1,155 @@
+---
+description: new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested
+mode: subagent
+---
+
+---
+name: agdf-gate-check
+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.
+---
+
+# gate-check
+
+## Purpose
+Determine the earliest blocking user approval gate and derive:
+
+- the active or blocking gate
+- whether the process is open or blocked
+- currently allowed outputs
+- currently forbidden outputs
+- the exact missing approval
+- the next permissible step
+
+This skill must not create later artefacts such as PRD, SD, TP, CD, CR, QA, or UAT when the gate does not allow them.
+
+## Runtime Contract
+Use `../agdf-runtime-contract.md` for gate terms, closeout discipline, and non-duplication rules.
+The canonical gate order and transition model live only in the Runtime Contract. This skill evaluates the current state against that model; it must not maintain a second complete gate table.
+
+## Agent-Native Control Path
+
+AGDF is agent-native first and CLI-verifiable by design.
+This skill is the primary operating path for gate judgement.
+
+First inspect the durable control state directly:
+
+- `.agdf/control/AGDF_RUN.md`
+- `.agdf/control/MASTER_BACKLOG.md`
+- `.agdf/control/SOT_REGISTRY.md`
+- `.agdf/control/CONTEXT_GRAPH.md`
+- `.agdf/control/AGENT_QUALITY_CONTRACTS.json`
+
+If required control files are missing, do not automatically create a full `.agdf/control/` scaffold for a fresh small request.
+The default first action is to draft the minimal UR in the response and request `Approval: UR`.
+Use `init` 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.
+
+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:
+
+```bash
+npx --yes agdf@latest init
+npx --yes agdf@latest doctor --json
+npx --yes agdf@latest gate-check --json
+npx --yes agdf@latest delivery-map --json
+```
+
+`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.
+`delivery-map` reports the durable delivery picture: active artefacts, approvals, Artefact Chain relationships, evidence refs, missing evidence, risks, Context Graph gate effect and machine-readable findings.
+
+The CLI reports are validators and JSON evidence, not the primary user experience, not a required ritual for normal work and not a second rule system. If a report says `blocked`, do not continue with later-gate artefacts until the reported blocker is resolved.
+
+## Rules
+1. Fail closed when a required approval or artefact status is missing.
+2. The earliest blocking gate wins.
+3. A user approval is valid only as `Approval: <GateName>`.
+4. Treat `Freigabe: <GateName>` as a legacy alias only when reviewing older German runs.
+5. Implicit consent is not approval. "ok", "go ahead", "do it", "approved", "continue", "leg los" and similar phrases do not unlock gates.
+6. Do not preview later artefacts while a gate blocks.
+7. Internal process steps are not user approval gates.
+8. OR-lite is allowed if it does not leak blocked content.
+9. SoT/runtime/product-semantics drift can trigger an early product gate, usually `UR`.
+10. Approval of one user gate permits work on the next allowed gate artefact or required internal step only; it never skips directly to implementation.
+11. New product semantics, functional change or user-visible behaviour change requires a durable UR in `.agdf/control/` or a linked authoritative repository SoT before Brownfield Review, PRD, SD, TP, Brownfield Analysis or implementation.
+12. Approval text and durable artefact presence are separate requirements for UR, PRD, SD, TP and QA report decisions. Approval text without the corresponding persisted or linked artefact keeps the current gate at that gate.
+13. After Brownfield Review, decide the process size before drafting PRD or implementing: `quick_task | structured_slice | structured_delivery | block`.
+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.
+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.
+
+## Gate Evaluation
+
+If `Approval: UR` is present, do not say implementation is the next step.
+The next step is Brownfield Review when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible; after that, the next step is a Mode/Slice Decision. Do not assume the full PRD/SD/TP chain before the existing-system impact is understood.
+Use the Runtime Contract's Gate Transition Model to derive the current gate, allowed outputs, forbidden outputs and missing approval.
+
+## When To Use
+- new user intent to build, add, change, extend, refactor or deliver something
+- Structured Delivery before first artefact creation
+- unclear current gate
+- user says "continue" or similar without exact approval
+- code or a later-gate artefact is requested
+- implementation permission is unclear
+- QA, UAT, or release permission is unclear
+
+Not required for simple Quick Tasks without new product scope and without formal artefacts.
+
+For a fresh prompt such as "I want to build a small CLI", use this skill first.
+Do not route directly to `agdf-brownfield-analysis` or implementation until this skill or live AGDF control state says that implementation preparation is the next allowed action.
+
+## Inputs
+Use what is available:
+
+- current user request
+- existing exact approvals
+- status of UR, PRD, SD, TP
+- Brownfield Review status
+- Mode/Slice Decision
+- Brownfield Analysis status
+- CD+Tests, CR, QA, UAT status
+- signs of documentation/runtime/product-semantics drift
+
+If a status is not explicit, do not assume it is satisfied.
+
+## Workflow
+1. Check exact approvals.
+2. Check artefact status.
+3. Determine the earliest blocking user gate or internal mandatory step.
+4. Derive allowed and forbidden outputs.
+5. Name the exact missing approval, if any.
+6. If consent was only implicit, say it is not yet approval and provide the exact formula.
+7. Ensure the next step follows the gate transition table. In particular, never jump from `Approval: UR` to implementation.
+8. Treat a generic "start", "continue" or "leg los" request as a request to perform only the current next allowed action.
+9. After Brownfield Review, choose the smallest safe process path before creating later artefacts.
+10. If the selected path is not visibly recorded with scope reason and evidence, keep the run at `Mode/Slice Decision`.
+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.
+
+## Output
+Keep the result short and operational:
+
+- **Current gate:** `<GateName or internal step>`
+- **Status:** `open | blocked`
+- **Allowed:** `<allowed outputs>`
+- **Forbidden:** `<forbidden outputs>`
+- **Missing approval:** `Approval: <GateName> | none`
+- **Next step:** `<single permissible next step>`
+
+If this skill creates or updates control artefacts, do not paste full file bodies into the chat.
+List paths, summarize the decision, name the blocker or approval needed, and keep the durable content in the files.
+
+## Forbidden
+This skill must not:
+
+- create PRD before UR approval
+- create PRD before required Brownfield Review is done or explicitly not_applicable
+- create PRD before Mode/Slice Decision is recorded
+- create SD before PRD approval
+- create TP while earlier gates block
+- suggest implementation immediately after `Approval: UR`
+- suggest implementation before Brownfield Review has explicitly selected `quick_task`
+- suggest implementation immediately after `Approval: PRD`
+- suggest implementation immediately after `Approval: SD`
+- treat "ok", "leg los", "go ahead", "approved" or similar wording as gate approval
+- perform full Brownfield Analysis unless explicitly requested
+- provide implementation snippets while implementation is gated
+- paste full `.agdf/control/` files, templates or artefact bodies into the chat unless the user explicitly asks for the full content
+- present QA or UAT as passed without evidence
+- present release as allowed without QA pass and UAT approval where required
+