create-agdf 0.14.4 → 0.20.0

package/generated/plugins/copilot/agdf/skills/contracts/ur-definition.md

@@ -0,0 +1,94 @@
+# AGDF Runtime Contract — UR Definition
+
+This contract guides `ur-definition` only after a non-authorizing, bound
+`skill_continuation` with `phase: ur_definition`. It creates no gate or persistence authority.
+
+## Binding and ownership
+
+Use only the returned governance_target, run_id, revision_id, artifact_path and template_path.
+template_path is the absolute, version-matched template owned by the installed plugin runtime.
+Repository copies under `.agdf/control/templates/` are derived scaffold references and never
+override this authoring source. Read the template without rewriting it; persist only artifact_path.
+A direct invocation first dispatches ur-definition; without a bound run follow the existing
+resolve_delivery_run assignment, then gate-check intake/resume with its expected_revision_id.
+Never use AGDF_RUN_ID, cwd, discovery or a previous approval as authority. Missing, stale,
+foreign, invalid or approved bindings require fresh control routing; do not write.
+Gate-check delegates UR content here and remains the read-only readiness/approval owner.
+PRD semantic preparation belongs to prd-definition. Semantic SD/TP preparation belongs to sd-definition/tp-definition; shared registration
+remains in gate-artifact-preparation.
+
+## Define the need
+
+Read the original request and answered context. Populate Problem, Goal, Affected Users,
+Scope, Non-Goals, Acceptance Signals, Existing Source Of Truth, Risks And Unknowns and Next Step.
+Keep user intent distinct from assumptions. Cite known repository owners where available;
+record unknown ownership without inventing facts. Do not invent users, scope, requirements,
+acceptance promises, approvals or downstream product/design decisions.
+
+### Preserve requested clarification deliverables
+
+For a user-facing change, capture what the user needs to see or try to judge the proposed behavior.
+When a preview, mockup or prototype is explicitly requested, preserve it as an actual deliverable
+in Scope: its purpose, user task, relevant states/scenarios, required interaction or format and
+when it is needed (for example before PRD approval). Record observable review success in Acceptance
+Signals and unresolved product questions in Risks And Unknowns. Use answered context; ask only if
+an ambiguity materially changes the requested deliverable. Do not turn an illustrative example into
+a requirement. Without an explicit preview commitment, do not impose one on unrelated or already
+clear requests.
+
+Distinguish a required preview from an optional clarification aid. An explicitly requested
+interactive preview cannot silently become a screenshot, static wireframe or written walkthrough.
+Preserve the requirement and name a concrete recovery or obtain an explicit scope change if it
+cannot be delivered. Record the responsible later UX/PRD step in Next Step; UR authoring still
+writes only its assigned UR, not a preview or product implementation. A requested before-PRD preview
+is created through UX intent clarification under the existing post-UR routing owner. Its durable
+output belongs to `.agdf/control/artefacts/<run_id>/previews/` for the bound run; the UX skill owns
+creation, versioning, evidence and references. An inline chat rendering alone does not fulfill that
+run deliverable. In a new UR, set exactly one initial metadata line before the first section:
+`Preview requirement: before_prd_interactive` for a required interactive before-PRD preview,
+otherwise `Preview requirement: none`. Preserve the task/scenarios in Scope and Acceptance
+Signals; the field cannot replace them. Missing markers in existing URs retain legacy semantics;
+do not retrofit an approved source or infer a requirement from prose/examples. Unknown or duplicate
+values require correction through the existing UR owner. This adds no gate or separate approval.
+
+When a missing fact materially changes the problem, intended users, scope or success signal,
+ask one bundled semantic clarification covering the actual gap. Do not ask for technical run
+identifiers or repeat answered questions. Preserve a useful draft with
+`Requirements clarification: open`; it is not ready for approval. If the concrete request is
+complete, draft immediately. Minor unknowns may be marked assumptions/deferred questions when
+they do not change the need; explain them, do not create redundant clarification loops.
+Set `Requirements clarification: complete` only when all required sections are concrete and
+no material requirement decision remains open. This is cooperative semantic judgement, not approval.
+Keep Status draft and Gate approval open.
+
+## Language and approval summary
+
+Use the continuation's `artifact_language` resolved from `.agdf/control/config.json` for
+the UR and its resolved `presentation_language` for user-facing text. Do not infer the
+artefact language from the request, template headings or runtime rules. The configured
+chat language is the direct-command default; explicit dispatcher presentation input
+follows its current-request language contract and does not change the artefact language.
+
+Before recording a complete draft, when `approval_summary_required` is true, include exactly
+one `## <approval_summary_heading>` section using the supplied heading verbatim. Write a
+complete summary in the resolved presentation language covering problem, goal, affected users,
+scope, non-goals, acceptance signals, source ownership, risks/unknowns and next step.
+Do not truncate decision-relevant content or use ellipses. The existing approval renderer's
+limits and validation apply. This summary is editorial; the UR remains authoritative.
+For new-format URs, a missing or invalid required summary returns to this same authoring
+route before presentation. Correct it through the existing revision writer; no user approval
+is required merely to complete an unapproved incomplete draft.
+
+## Revision and recording
+
+A new draft is recorded through existing run-step --step ur --title <short title>, using
+--dir <governance_target> --run <run_id> --revision <revision_id>.
+For an already registered unapproved draft, require explicit user revision intent. Resume
+through gate-check with intake true, intake_mode resume, run_id, expected_revision_id and
+ur_action revise (CLI --ur-action revise). Ordinary intake of a ready draft still presents it.
+After editing a registered draft use existing run-update, not run-step: the previous seal
+must be replaced by the canonical revision writer. Never edit an approved UR or its approval.
+Use the returned new revision, redispatch gate-check for this target/run, prepare the fresh
+run-present when supplied, show its returned text verbatim and wait for a NEW deliberate
+`Approval: UR`. Previous presentations/replies cannot approve a changed draft.
+After valid UR approval, existing Brownfield Review and Mode/Slice routing continue unchanged.

package/generated/submissions/openai/agdf/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agdf",
-  "version": "0.14.4",
+  "version": "0.20.0",
   "description": "Control layer for governed AI-assisted delivery.",
   "author": {
     "name": "Arndt Gold",

package/generated/submissions/openai/agdf/meta/agdf-agent-router.md

@@ -23,12 +23,34 @@ Therefore plugin skill names are intentionally unprefixed:
 - `delivery-closeout`
 
 Do not duplicate the plugin namespace in Codex or Claude Code plugin skill names.
-That `agdf-` prefix is reserved for GitHub Copilot repository skills, where no plugin namespace exists.
+Copilot and local OpenCode skills use `agdf-`; global OpenCode skills use `agdf-global-`.
+The dispatcher resolves exact host names from the shared catalog to stable canonical IDs.
+Technical `skill_id`, `--skill` and contract references always use canonical IDs.
+
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:START -->
+## Request Activation
+
+- `owner`: `request_activation_contract`
+- `path`: `meta/contracts/request-activation.md`
+- `policy_version`: `1`
+- `guard_fingerprint`: `sha256:af2f01f9e18a3ba1c520faf0691aa1cd4a4299bdfa027cf83651c5d14319bfdc`
+
+Decide effect from loaded instructions before AGDF action.
+
+Abstain silently (no AGDF call) for assessment/explanation/comparison/recommendation/review/diagnosis/advice; hypothetical/example/error/code/quoted/negated delivery language; AGDF as subject; or a read-only constraint absent other delivery. Ambiguity is read-only: answer or ask one neutral question.
+
+Activate for any requested file/code change however small, a binding gate artefact, explicit AGDF/control-lifecycle operation or unambiguous active-run action; delivery wins mixed intent.
+
+Invocation proof: explicit user text/trusted ephemeral action, not discovery/selection, skill load, hooks, cwd, repo/control or prior runs.
+
+Then pick one catalog route; non-authorizing, downstream checks remain.
+<!-- AGDF-REQUEST-ACTIVATION-GUARD:END -->
 
 ## Task Target Resolution
 
-Before repository activation, Mode Selection or `gate-check`, resolve or revalidate the primary work
-target through `contracts/task-target-resolution.md`.
+Only after positive Request Activation, and only for a target-bound route, resolve or revalidate the
+primary work target through `contracts/task-target-resolution.md` before repository activation,
+Mode Selection or `gate-check`.
 
 An explicit file, artefact or repository named as the work target outranks the current working
 directory. A repository mentioned or inspected as evidence does not gain mutation or governance
@@ -41,9 +63,13 @@ file or an evidence source. A confirmed target may continue across related turns
 unambiguous revalidation; a new explicit target wins and ends the old binding.
 
 ## Mode Selection
+This section is downstream of positive Request Activation. A request that abstained or remained an
+ordinary read-only request never enters AGDF Mode Selection or Quick Task handling.
+
 Default entry rule: a new user intent to build, add, change, extend, refactor or otherwise deliver something starts with `gate-check` unless it is clearly only a question, explanation, local inspection, or explicitly scoped review.
 
-Use Quick Task Mode for questions, small reviews, local debugging and narrow fixes without new product semantics. Use Verified Change only after approved UR and Brownfield Review when the Runtime Contract's compact record can prove bounded ownership, clean-at-baseline paths, prohibited-impact absence and deterministic validation.
+Use Quick Task Mode only for a positively activated request that remains a local debugging task,
+operational task or narrow fix without new product semantics. Size lightens the mode, never activation. Use Verified Change only after approved UR and Brownfield Review when the Runtime Contract's compact record can prove bounded ownership, clean-at-baseline paths, prohibited-impact absence and deterministic validation.
 
 Use Structured Delivery Mode for new capabilities, architecture, policy, persistence, release-critical work, formal artefacts or explicit approvals.
 
@@ -54,6 +80,12 @@ Do not infer approval from "ok", "go ahead", "do it", "approved", "continue", "l
 Those phrases may express intent to proceed, but they do not unlock a gate unless the exact gate formula is present.
 Do not infer active scope from branch names, uncommitted workspace deltas, chat history or generated summaries when durable artefacts point elsewhere.
 If multiple active scopes are plausible, list the evidenced lines and route to `gate-check` or workstate clarification instead of choosing silently.
+Before UR approval, delegate the bound requirement draft and material clarification to
+`ur-definition`. After approved UR and completed analysis/routing, delegate bound PRD drafting
+and clarification to `prd-definition`. After approved PRD, delegate bound design drafting and
+clarification to `sd-definition`. After approved SD, delegate bound planning and clarification to
+`tp-definition`. Gate-check keeps control, readiness and presentation ownership.
+
 After `Approval: UR`, run lightweight Brownfield Review before PRD when Brownfield, ownership, runtime, policy, persistence, architecture, UI or UX impact is possible.
 Brownfield Review must produce a Mode/Slice Decision: `quick_task`, `verified_change`, `structured_slice`, `structured_delivery` or `block`.
 That same review records the shared UI/UX impact classification. Run `ux-intent-definition` before
@@ -68,20 +100,28 @@ Narrow defect work may use the Runtime Contract's Bug Lightweight Track only whe
 Structured Delivery Mode must respect gates, reviews and closeout discipline.
 
 ## Skill Routing
+<!-- AGDF-SKILL-ROUTING:START -->
 | Skill | Use For | Boundary |
 |---|---|---|
 | `delivery-path-search` | high-impact planning decisions with several plausible next delivery steps before implementation | read-only advisory search; never grants gate permission or replaces gate-check |
-| `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 |
-| `ux-intent-definition` | after approved UR and post-UR routing for medium/high UI/UX impact or ambiguous low-impact product semantics before PRD readiness | non-authorizing analytical PRD input; never creates product intent, gate permission, technical design or a parallel product source of truth |
+| `brownfield-analysis` | permitted Brownfield Review or preparation before non-trivial existing-system changes | clarifies reuse, owners, risks and Mode/Slice; never bypasses control or grants implementation |
+| `ux-intent-definition` | approved UR with routed medium/high UX impact or ambiguous low-impact semantics before PRD | analytical PRD input only; no intent, gate, design or parallel product authority |
 | `clean-implementation-review` | evidence dimension: inspect whether the solution is structurally clean | supports Quality Readiness; not a TP or QA substitute |
 | `code-review` | evidence dimension: review the actual diff for defects, regression and security findings | supports Quality Readiness; does not replace QA |
 | `delivery-closeout` | commit/PR-near handoff after QA/OR/UAT | never performs VCS actions automatically |
-| `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 |
+| `ur-definition` | bound UR drafting, clarification or revision | content only; preserves approved intent |
+| `prd-definition` | bound PRD drafting, clarification or revision | content only; preserves approved intent |
+| `sd-definition` | bound SD content | content only; preserves approved intent |
+| `tp-definition` | bound TP content | content only; preserves approved sources |
+| `gate-check` | delivery control and gate readiness | delegates drafts; never approves or skips gates |
 | `qa-gate` | sole final Quality Readiness decision | only instance for `pass | revise | block` |
 | `release-or` | auditable closeout for every relevant run | not a QA substitute |
 | `task-plan-review` | evidence dimension: verify whether the approved Task Plan was fulfilled | supports Quality Readiness; no final QA decision |
+<!-- AGDF-SKILL-ROUTING:END -->
 
-Select exactly one primary skill first.
+For named operations, use the catalog owner in `contracts/request-activation.md`; active-run
+inventory uses `control.doctor` with all-active inspection.
+For skill or delivery routes, select exactly one primary skill first.
 Add more only when they cover a distinct concrete risk dimension.
 Do not choose `brownfield-analysis` as the first primary skill for a fresh "I want to build/change X" prompt unless `gate-check` or existing live AGDF control state already makes implementation preparation the next allowed action.
 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.
@@ -89,6 +129,7 @@ Never jump directly from `Approval: UR`, implicit consent, or a generic "start"
 ## Runtime Contract
 For repeated output, gate, Quality Contract and Context Graph rules, use:
 
+- `contracts/request-activation.md` for pre-target request applicability, operation routing and silent abstention
 - `contracts/task-target-resolution.md` for primary target authority before repository activation
 - `contracts/gate-transition.md` for gate terms, Brownfield routing and transition rules
 - `contracts/interaction.md` for status cards, approval orientation and native interaction
@@ -107,6 +148,7 @@ When the target repository uses the AGDF control scaffold, keep live control fil
 Use templates as starting points only.
 
 Do not let chat history become the source of truth for gate state, approvals, evidence, backlog status or durable Brownfield knowledge.
+After editing a run or its listed artefacts, record the revision with the dispatch validator's `run-update` before `gate-check`; record an exact gate reply only with `run-approve`, never by editing Approvals.
 
 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.
 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.