create-agdf 0.14.4 → 0.20.0

package/generated/plugins/copilot/agdf/runtime/create-agdf/generated/plugins/agdf/meta/contracts/request-activation.md

@@ -0,0 +1,252 @@
+# AGDF Runtime Contract — Request Activation
+
+## Purpose And Authority
+
+Request Activation decides whether the current user request may enter an AGDF operation. It runs
+before task-target resolution, repository activation, control inspection, run or gate selection,
+dispatcher v1, AGDF presentation, and mutation.
+
+This contract is the sole semantic owner for request applicability, requested-effect precedence,
+invocation provenance, selection origin, the bounded operation catalog, and silent abstention. It
+does not resolve a target, inspect a repository, validate control, select a run, evaluate a gate,
+render AGDF output, or authorize work.
+
+The decision is request-scoped and transient:
+
+- no raw prompt or derived request classification is written to disk, logs, control state, or a new
+  telemetry field;
+- no network request, remote classifier, repository read, tool call, or dispatcher call is needed
+  to make the semantic decision;
+- passive SessionStart context, installed-plugin presence, cwd, repository presence, durable control,
+  a prior unrelated run, router selection, and automatic skill discovery are not activation evidence;
+- exact approval, target, run, gate, lifecycle, status, and presentation authority remains with the
+  existing downstream owners after positive applicability.
+
+## Transient Decision
+
+```text
+policy_version: 1
+requested_effect:
+  read_only_assistance
+  | governed_delivery
+  | binding_delivery_artefact
+  | named_agdf_operation
+  | control_lifecycle
+  | continuation_action
+  | ambiguous
+request_class:
+  ordinary_read_only
+  | delivery_intent
+  | explicit_agdf_operation
+  | explicit_control_lifecycle
+  | active_run_continuation
+  | ambiguous_effect
+decision:
+  abstain
+  | clarify
+  | activate_named_operation
+  | activate_delivery_intake
+  | activate_continuation
+invocation_provenance:
+  current_user_text
+  | trusted_ephemeral_user_action
+  | unavailable
+selection_origin:
+  explicit_user_action
+  | automatic_discovery
+  | router_selection
+  | unavailable
+operation_id: optional identifier from the bounded operation catalog
+authorizes: false
+persist: false
+```
+
+| Request class | Requested effect | Decision |
+|---|---|---|
+| `ordinary_read_only` | Assessment, explanation, comparison, recommendation, review, diagnosis, hypothetical or advisory implementation discussion, or AGDF discussed only as a subject. | `abstain` |
+| `delivery_intent` | An actual governed change, fix, refactor, implementation, or other delivery effect is requested. | `activate_delivery_intake` |
+| `delivery_intent` | A binding gate-relevant delivery artefact is requested. An example, template, recommendation, or advisory draft is not binding. | `activate_delivery_intake` |
+| `explicit_agdf_operation` | The current request expressly invokes AGDF, a supported skill, or a named AGDF help, suitability, status, run, gate, audit, approval, quality, or closeout operation. Merely naming AGDF as the subject of a question is not invocation. | `activate_named_operation` |
+| `explicit_control_lifecycle` | The current request expressly asks to initialize or validate durable `.agdf/control`, inspect its lifecycle or validity, or perform supported target-bound repository activation or disablement. | `activate_named_operation` |
+| `active_run_continuation` | The request asks to perform the immediately pending action for an active run, supplies its exact pending approval, or unambiguously answers that pending action. Merely asking about the run or gate is named read-only inspection, not continuation. | `activate_continuation` |
+| `ambiguous_effect` | The requested effect cannot be determined reliably and no explicit mutation or binding delivery output is established. | `abstain` when useful read-only assistance is possible; otherwise `clarify` |
+
+Determine the requested effect, not the presence of delivery-related words. Quoted, negated,
+hypothetical, example, error-message, and code-block text does not become a current delivery request.
+When a mixed request actually asks for both assessment and a delivery effect, delivery intent wins.
+When no actual delivery effect is requested, ambiguity stays read-only and never activates AGDF by
+default.
+
+Apply precedence in this order:
+
+1. An explicit request for a supported AGDF or control-lifecycle operation activates exactly that
+   named operation. AGDF discussed only as a subject does not.
+2. An actual requested mutation or binding delivery outcome activates delivery even when assessment,
+   explanation, or recommendation is also requested.
+3. An explicit constraint such as `do not implement` or `only assess` keeps the constrained work
+   read-only unless another actual delivery effect remains.
+4. Delivery language inside quotations, examples, code, errors, negations, or hypothetical advice is
+   context only.
+5. Active-run continuation requires current-turn action intent or an immediately bound action
+   response. A read-only question about a run or gate is a named inspection operation, not
+   continuation, and an unrelated later request inherits no activation.
+6. Without reliable positive evidence, choose ordinary read-only handling or ambiguous effect. Never
+   default to activation.
+
+## Invocation Provenance And Selection Origin
+
+`requested_effect`, `invocation_provenance`, and `selection_origin` are independent values.
+
+- Current-turn text that explicitly requests AGDF or a supported operation is sufficient provenance.
+- A host signal is accepted only when it is trusted, ephemeral, bound to the current deliberate user
+  action, and grants no approval or target authority.
+- Automatic discovery, router selection, skill loading, and passive hook output are selection origin,
+  never invocation provenance.
+- When invocation provenance is unavailable, the requested effect remains decisive. Selection origin
+  alone never activates AGDF.
+
+## Operation Catalog
+
+The following JSON block is the complete logical operation catalog. It maps an already determined
+positive request class to one existing route owner; it is not a natural-language classifier. Entries
+whose `owner_kind` is `command` must resolve through the existing `commandRegistry`. The
+`delivery.start` skill owner and every derived direct-skill ID must resolve through
+`pluginDefinition.skillSet`. Function owners remain downstream implementation owners and do not
+grant applicability or authority.
+
+<!-- AGDF-REQUEST-ACTIVATION-OPERATIONS:START -->
+```json
+{
+  "schema_version": 1,
+  "operations": [
+    { "operation_id": "assist.agdf_help", "route_family": "control_independent_help", "target_boundary": "explicit_optional", "control_boundary": "no_probe", "owner_kind": "contract", "owner": "request_activation_contract" },
+    { "operation_id": "assist.agdf_suitability", "route_family": "control_independent_help", "target_boundary": "explicit_optional", "control_boundary": "no_probe", "owner_kind": "contract", "owner": "request_activation_contract" },
+    { "operation_id": "delivery.start", "route_family": "governed_delivery_intake", "target_boundary": "required_after_activation", "control_boundary": "presence_then_dispatcher_revalidation", "owner_kind": "skill", "owner": "gate-check" },
+    { "operation_id": "lifecycle.control.init", "route_family": "repository_control_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "absence_allowed", "owner_kind": "command", "owner": "init" },
+    { "operation_id": "lifecycle.repository.activate.codex", "route_family": "repository_surface_lifecycle", "target_boundary": "explicit_required", "control_boundary": "no_delivery_invention", "owner_kind": "command", "owner": "codex-repo" },
+    { "operation_id": "lifecycle.repository.activate.opencode", "route_family": "repository_surface_lifecycle", "target_boundary": "explicit_required", "control_boundary": "no_delivery_invention", "owner_kind": "command", "owner": "opencode-repo" },
+    { "operation_id": "lifecycle.repository.disable", "route_family": "repository_surface_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "existing_owner", "owner_kind": "command", "owner": "disable" },
+    { "operation_id": "lifecycle.plugin.install.codex", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "codex" },
+    { "operation_id": "lifecycle.plugin.install.claude", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "claude" },
+    { "operation_id": "lifecycle.plugin.install.copilot", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "copilot" },
+    { "operation_id": "lifecycle.plugin.install.opencode", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "opencode" },
+    { "operation_id": "lifecycle.plugin.uninstall", "route_family": "global_plugin_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "uninstall" },
+    { "operation_id": "status.installation.codex", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.installation.claude", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.installation.copilot", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.installation.opencode", "route_family": "global_installation_status", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "function", "owner": "inspectGlobalInstallationStatus" },
+    { "operation_id": "status.overview", "route_family": "status_overview", "target_boundary": "explicit_or_reliably_resolved_optional", "control_boundary": "repository_component_only_after_target", "owner_kind": "function", "owner": "evaluateStatusOverview" },
+    { "operation_id": "status.repository_delivery", "route_family": "repository_status", "target_boundary": "explicit_required", "control_boundary": "absence_is_result", "owner_kind": "function", "owner": "evaluateGeneralStatus" },
+    { "operation_id": "status.opencode_repository", "route_family": "repository_status", "target_boundary": "explicit_required", "control_boundary": "absence_is_result", "owner_kind": "function", "owner": "evaluateOpenCodeStatus.repository" },
+    { "operation_id": "runtime.checks", "route_family": "global_runtime_lifecycle", "target_boundary": "none", "control_boundary": "no_probe", "owner_kind": "command", "owner": "runtime-checks" },
+    { "operation_id": "control.doctor", "route_family": "deterministic_control_inspection", "target_boundary": "required_after_activation", "control_boundary": "missing_is_result", "owner_kind": "command", "owner": "doctor" },
+    { "operation_id": "control.delivery_map", "route_family": "deterministic_control_inspection", "target_boundary": "required_after_activation", "control_boundary": "missing_is_result", "owner_kind": "command", "owner": "delivery-map" },
+    { "operation_id": "run.create", "route_family": "run_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "command_preconditions", "owner_kind": "command", "owner": "run-create" },
+    { "operation_id": "run.migrate", "route_family": "run_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "command_preconditions", "owner_kind": "command", "owner": "run-migrate" },
+    { "operation_id": "run.render_legacy", "route_family": "run_lifecycle", "target_boundary": "required_after_activation", "control_boundary": "command_preconditions", "owner_kind": "command", "owner": "run-render-legacy" },
+    { "operation_id": "continuation.current", "route_family": "active_run_continuation", "target_boundary": "required_after_activation", "control_boundary": "target_run_gate_revalidation", "owner_kind": "function", "owner": "existingTargetRunGateRevalidators" }
+  ],
+  "derived_operations": [
+    { "operation_id_pattern": "skill.<slug>", "route_family": "direct_skill", "derive_from": "pluginDefinition.skillSet", "target_boundary": "dispatcher_v1", "control_boundary": "dispatcher_v1", "owner_kind": "dispatcher", "owner": "skill-dispatch-v1" }
+  ]
+}
+```
+<!-- AGDF-REQUEST-ACTIVATION-OPERATIONS:END -->
+
+Route boundaries:
+
+- `assist.*`, global plugin lifecycle, global runtime checks, and global installation status never
+  invent a repository target or probe repository control.
+- `status.overview` always returns its targetless global component. It adds repository or delivery
+  status only after explicit or reliably resolved target evidence; cwd is never implicit authority.
+- Repository lifecycle, repository status, Doctor, Delivery Map, and run lifecycle resolve a target
+  only after positive applicability and then call only their declared owner.
+- `skill.<slug>` invokes dispatcher v1 as the first operational call. There is no preceding target,
+  repository, control, run, gate, or renderer call.
+- `delivery.start` may resolve target and inspect structural control presence for draft/setup only.
+  Candidate control is not actionable evidence; dispatcher v1 revalidates target and control before
+  any gate result.
+- Active-run continuation establishes applicability from action intent, then revalidates target, run,
+  gate, revision, and exact approval through existing owners.
+
+Missing control is route-specific. Help and suitability answer normally; status reports unavailable
+control or run state; gate-dependent operations block on missing evidence; explicit lifecycle setup
+uses its existing recovery; continuation requests restoration or selection of the referenced run;
+delivery intake drafts and persists a real UR before any approval presentation. No missing-control
+route synthesizes an immediate `Approval: UR` merely because a control file is absent.
+
+## Active Run Inventory
+
+"Zeige die aktiven AGDF-Runs in diesem Projekt" / "Show the active AGDF runs in this project"
+selects `control.doctor`, even with gate-check loaded. For "this project", bind its verified chat
+repository root as `primary_target`, `target_source: current_repository`; cwd alone is not authority.
+Ambiguous or unavailable projects use existing target clarification.
+Call `agdf_inspect` with `operation: doctor`, `all_active: true`, `presentation_language` and actual
+`working_directory`; fallback: surface-local `doctor --dir <verified-root> --all-active --json`.
+Omit run selection, intake and continuation. Show every returned run plus integrity findings.
+Distinguish empty, absent control, incomplete inventory and failure; partial counts are not totals.
+Listing never repairs, initializes or requests approval.
+
+## Request Applicability Guard
+
+The block below is the only compact guard source. It is projected byte-for-byte into the canonical
+router and every canonical skill before any operational boundary. Generated surfaces may transform
+only host-specific skill names and resource paths outside this block.
+
+The `guard_fingerprint` is SHA-256 over the complete marker-bounded block after replacing its own
+hex value with `<computed>` and normalizing line endings to LF. The projection tool owns that derived
+field and every copied marker region; missing, partial, duplicate, reordered, or manually edited
+regions fail check mode.
+
+<!-- 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 -->
+
+## Discovery Description Suffix
+
+The single sentence below is appended to every skill frontmatter description after the
+definition-owned `useFor` and `boundary` values.
+
+<!-- AGDF-REQUEST-ACTIVATION-DISCOVERY-SUFFIX:START -->
+The requested effect, not discovery, decides AGDF activation.
+<!-- AGDF-REQUEST-ACTIVATION-DISCOVERY-SUFFIX:END -->
+
+## Failure Semantics
+
+- `abstain` and `clarify` cause zero request-driven calls to dispatcher v1, target resolution,
+  repository activation, control presence, run selection, control evaluation, AGDF rendering,
+  lifecycle, status, or mutation owners.
+- A partial, missing, duplicate, stale, or fingerprint-mismatched guard fails generation and Runtime
+  Integrity. It never falls back to the previous broad trigger.
+- A missing or unknown operation ID stops at routing. It is not reinterpreted as `delivery.start` or
+  generic `gate-check`.
+- No hook, generated profile, test fixture, installed runtime, keyword list, or host-specific prompt
+  becomes another request-applicability owner.
+
+
+### Delivery intent transport
+
+A delivery request without a confirmed run binding first dispatches gate-check with intake true
+and no run_id. Its resolve_delivery_run continuation supplies canonical UR scope evidence for the
+coding agent's assignment. One unequivocal same-scope continuation uses resume, its run_id and
+expected_revision_id; a clear independent scope uses new and an unused run_id even when unrelated
+runs exist. Single-run count, recency, shared files and ambient AGDF_RUN_ID prove no scope match.
+Overlapping plausible scopes require one question about the work, not a technical Run-ID choice.
+Incomplete inventory is a technical failure, never evidence for a new scope. Read-only requests omit intake and
+continue_delivery. On a bound run, continue_delivery requests the next canonical internal
+continuation listed in the interaction contract without another user prompt; it approves no gate.

package/generated/plugins/copilot/agdf/runtime/create-agdf/generated/plugins/agdf/meta/contracts/sd-definition.md

@@ -0,0 +1,69 @@
+# AGDF Runtime Contract — SD Definition
+
+Use only a bound skill_continuation with phase sd_definition. This contract owns semantic
+design drafting and clarification; it adds no gate, writer, persistence or approval authority.
+
+## Binding and sources
+
+Dispatch before direct work. Unbound invocation uses the existing resolve_delivery_run inventory,
+matching original need to approved scope, then revision-bound gate-check resume intake. Never
+select AGDF_RUN_ID, invent a run, infer editing intent from discovery/selection or use cwd as
+authority. Use only returned governance_target, run_id, revision_id, artifact_path, absolute
+plugin-owned template_path and sources. The installed, version-matched plugin is the sole
+authoring-template authority; repository scaffold copies never override it. Missing or unsafe
+template_path blocks authoring without mutation or fallback and requires explicit plugin repair.
+Read the exact approved PRD, resolved product decisions, completed Brownfield routing and required
+ready analytical inputs. PRD is product authority; analyses are subordinate. Missing/stale/foreign/
+approved bindings or unrelated prerequisite/integrity/source blockers require fresh control.
+
+## Draft and clarify
+
+Use the existing SD format and one canonical unapproved design: draft/open metadata, named Owner,
+Solution Overview, Ownership And Source Of Truth, Architecture Decisions, Integration Points,
+Constraints And Compatibility, Test And Evidence Strategy, Acceptance Traceability, Risks And
+Open Questions, Design Decisions, Next Step. Retain criteria-chain-v1. Explain architecture,
+boundaries, flows, reuse, alternatives, rationale and trade-offs at proportionate depth. Map every
+PRD criterion exactly once to realization, authoritative owner, stable SDD IDs or reasoned none
+and compatibility/risk. Never duplicate acceptance, invent scope/users or claim implementation.
+Retain actual sources/draft and a reasoned derivation review; structure alone is not semantic proof.
+
+Always declare Design Decisions contract: sd-decisions-v1 and exactly one Design Decisions table:
+Decision | Timing | Status | Resolution | Owner. Unique decisions use before_sd or later_tp,
+status resolved/open/deferred, named owner and concrete resolution or deferral reason. Material
+architecture/design choices belong before_sd and must be resolved before presentation. later_tp
+may defer execution/test/evidence detail only; never hide binding architecture or product intent.
+With no material unknown, record a concrete resolved applicability decision, not an empty table.
+Legacy unmarked designs retain existing checks; this never permits removing a new draft's
+declaration/table to conceal questions. Declared readiness does not prove all questions were found.
+
+Missing material facts: preserve a useful draft and before_sd open row, retain answered context
+and ask one focused bundled question. Sufficient inputs need no redundant question. Record confirmed
+answers and updated design through the checked writer, then re-evaluate. Specific decision or
+traceability correction permission never removes its blocker or unrelated source/integrity checks.
+A product-scope/acceptance conflict stays unresolved and returns to the earliest affected existing
+UR/PRD revision owner. Do not edit approved sources, invent a transition after downstream linking
+or manufacture answers; use supported revision/recovery and fresh source approval where required.
+
+## Explicit revision and recording
+
+Before recording, use the continuation's resolved language and summary fields with
+gate-artifact-preparation's Language and approval summary preparation. A translated summary
+must be part of the draft before presentation, not deferred until a renderer failure.
+
+A ready registered draft requires actual human editing intent; skill loading/selection is not
+permission. Ordinary continuation presents its current result. Explicit canonical revision uses
+gate-check intake true, intake_mode resume, run_id, expected_revision_id and sd_action revise
+(CLI --sd-action revise), exclusive of UR/PRD actions and continue_delivery. Never edit an
+approved design or transfer approvals. Source-intent changes use their existing revision owner.
+
+Use gate-artifact-preparation's shared Reviewed Recording Input with the supplied run/revision:
+run-step --step artefact --gate SD --evidence <recording-input.json>. Record SD-derived_from-PRD
+from its exact approved source. Initial registration uses update_draft false; permitted explicit
+replacement uses true with fresh mapping/input paths, preserving previous proof/history and
+other protected bytes. No hand-authored receipt, run-update bypass or unknown-edit reseal.
+Use supported transaction/recovery with fresh state on failure.
+
+Redispatch gate-check after recording. Prepare its exact run-present when supplied, show returned
+text verbatim and wait for a NEW deliberate Approval: SD. Changed drafts require fresh presentation;
+old replies cannot approve new content. Use the existing localized summary when languages differ.
+Only valid approval permits existing TP drafting; this skill creates no TP, code, QA or release.

package/generated/plugins/copilot/agdf/runtime/create-agdf/generated/plugins/agdf/meta/contracts/task-target-resolution.md

@@ -0,0 +1,156 @@
+# AGDF Runtime Contract — Task Target Resolution
+
+## Purpose And Ordering
+
+After positive Request Activation, resolve the user's primary work target before repository
+activation, Scope Classification, mode selection or gate evaluation for routes that require a
+target. Repository governance is downstream of the task target; the current working directory, an
+inspected repository or a source mentioned as evidence must never become the work target by
+accident. Silent Request Activation abstention and targetless catalog routes do not invoke this
+contract.
+
+The canonical order after Request Activation selected a target-bound route is:
+
+1. resolve or revalidate the task target;
+2. derive the governance target from that resolved target;
+3. activate repository-local AGDF control only for that governance target;
+4. then apply read-only orientation, Scope Classification, mode selection and gate evaluation.
+
+If task-target resolution is unresolved, steps 2–4 and every mutation are forbidden. The unresolved
+result is terminal for the current response and overrides continuation, missing-control, fresh-UR
+and approval branches. Prior chat artefacts, runs and approvals remain candidate context only; they
+must not produce a conditional gate result until one target is resolved.
+
+## Direct Skill Invocation Preflight
+
+After the already-loaded Request Activation guard has positively selected a direct, target-bound
+skill route, every canonical AGDF skill invocation starts with this preflight before skill-specific
+input discovery, repository inspection, run selection, gate evaluation, quality evaluation or
+mutation. This applies equally when a user invokes a skill explicitly and when the agent router
+selected it. Automatic selection alone is not positive activation; on silent abstention this
+preflight is not run.
+
+1. Determine the current conversation language for presentation. A German user turn or an ongoing
+   German conversation uses `de`; an unsupported language falls back to the complete English locale
+   pack through the Interaction Contract.
+2. Resolve or revalidate the primary target under Target Authority Precedence. When an exact-version
+   surface-local validator is available, use one of the existing `target-check --json` forms below.
+3. Validate the normalized Resolution Result. Do not infer missing fields from cwd, chat storage,
+   an inspected repository, a prior run or evidence sources.
+4. If `resolution_state` is `unresolved`, consume `task_target_orientation.markdown` verbatim from
+   the Interaction Contract, request only the normalized `next_action` in the same presentation
+   language and stop the current skill invocation. This is a terminal pre-decision outcome: do not
+   inspect repository control state, select a run, evaluate a gate or quality decision, produce the
+   skill's normal output, or mutate files.
+5. If `resolution_state` is `resolved`, use only its `governance_target` for downstream repository,
+   run, gate and evidence access. Revalidate after an explicit target change and before every
+   mutation or gate decision.
+
+The resolved `presentation_language` remains binding for the complete user-facing interaction:
+target orientation, clarification and subsequent skill-owned chat output must not mix locale packs.
+Durable artefacts, machine fields, task identifiers and exact approval values retain their canonical
+language as defined by the Interaction Contract.
+
+Context-only form when no reliable target is selected:
+
+```bash
+node <surface-local-agdf> target-check --json --language <current-chat-language> --working-directory <absolute-path>
+```
+
+Selected-target form:
+
+```bash
+node <surface-local-agdf> target-check --json --language <current-chat-language> --target-source <explicit_target|continued_target|current_repository> --primary-target <absolute-path> --working-directory <absolute-path>
+```
+
+The two forms are validation paths, not permission to invent a target or contact a registry. If no
+exact-version surface-local validator exists, continue agent-natively only as far as the observable
+evidence permits and report machine validation as unavailable. Do not install or resolve a remote
+runtime during ordinary skill invocation.
+
+## Resolution Result
+
+Use one normalized result:
+
+- `resolution_state`: `resolved | unresolved`
+- `reason_code`: `explicit_target | continued_target | multiple_plausible_targets |
+  target_content_mismatch | target_unavailable | no_reliable_target | target_source_invalid`
+- `primary_target`: exactly one requested work object when resolved, otherwise empty
+- `evidence_sources`: zero or more mentioned or inspected sources that do not gain mutation authority
+- `working_directory`: execution context only, never target authority by itself
+- `governance_target`: the repository whose control state applies to the primary target, otherwise empty
+- `target_changed`: whether an explicit new target replaced the previously confirmed target
+- `next_action`: required clarification, supply or retry action when unresolved
+- `input_error`: present only for invalid target-selection input; contains the canonical `field` and
+  `allowed_values` without echoing the rejected value
+
+A resolved result requires a non-empty `primary_target` and a reason code of `explicit_target` or
+`continued_target`. An unresolved result requires an empty `primary_target`, an empty
+`governance_target`, one of the five unresolved reason codes and a non-empty `next_action`.
+Contradictory or incomplete results fail closed.
+
+## Target Authority Precedence
+
+Resolve in this order:
+
+1. an explicit file, artefact or repository named as the work target in the current user turn;
+2. a previously confirmed target only when the current turn unambiguously continues the same action,
+   object and scope;
+3. the current repository or working directory only when the request explicitly or deictically asks
+   for work on "this project", "this repository" or an equivalent current-scope reference;
+4. otherwise `no_reliable_target`.
+
+An explicit current-turn target always replaces an inherited target. Make the change visible when
+the previous target could otherwise remain plausible.
+
+Do not fall back to the working directory, a neighboring file or an evidence source when the
+explicit target is unavailable or its content does not support the requested change.
+
+## Evidence And Mutation Boundary
+
+Reading, inspecting, mentioning or relying on a repository or artefact makes it an evidence source,
+not a mutation target. Evidence access never grants mutation authority and never activates that
+repository's AGDF control state.
+
+Derive `governance_target` only from:
+
+- the repository containing the resolved `primary_target`; or
+- an explicit user statement that a named repository governs the target.
+
+An external standalone artefact may have no repository governance target. In that case the router
+continues with the applicable non-repository path; it must not borrow governance from the current
+working directory.
+
+## Continuation And Target Change
+
+A confirmed target may continue across related turns only when the current request remains
+unambiguous. Revalidate it before every mutation or gate decision. New explicit target evidence wins.
+New ambiguity ends the inherited binding and produces `multiple_plausible_targets`.
+
+When a durable AGDF run exists, its Source And Scope State may record the confirmed target as
+evidence. It does not override a newer explicit user target. Outside a run, continuation remains
+transient conversation state; do not create a global target store or a second run-state owner.
+
+## Fail-Closed States
+
+- `multiple_plausible_targets`: more than one work target remains plausible; list the candidates and
+  request the smallest clarification.
+- `target_content_mismatch`: the requested content change is not supported by the explicit target's
+  observable content; name the mismatch and ask whether the target or requested change should change.
+- `target_unavailable`: the named file, attachment or artefact cannot be inspected; request supply or
+  access and offer a visible retry.
+- `no_reliable_target`: neither an explicit target nor an unambiguous continuation exists; request a
+  target.
+
+These states forbid repository activation, Scope Classification, gate evaluation and mutation.
+Never silently expand scope to make the request fit a different project.
+
+## Presentation Boundary
+
+`contracts/interaction.md` owns the visible, non-authorizing Task Target Orientation.
+`packages/core/lib/interaction-presentation.js` owns its rendering. The renderer projects a normalized
+result; it must not resolve targets, derive governance or become a state store.
+
+Show orientation when target/context separation is material, when the target changes, or when the
+result is unresolved. Avoid redundant presentation for an obvious unchanged target. Presentation
+never grants mutation or gate authority.

package/generated/plugins/copilot/agdf/runtime/create-agdf/generated/plugins/agdf/meta/contracts/tp-definition.md

@@ -0,0 +1,81 @@
+# AGDF Runtime Contract — TP Definition
+
+Use only a bound skill_continuation with phase tp_definition. This is the semantic Task/Test
+Plan author, never a gate, writer, approval or implementation authority.
+
+## Binding and content
+
+Use the returned target/run/revision, destination, exact approved PRD/SD and analytical sources,
+resolved languages and installed plugin-owned template_path. Missing/unsafe templates stop before
+writing; repository scaffold copies are no fallback. Unbound invocation uses the existing scope
+inventory, then revision-bound gate-check intake. Ambient runs, cwd, selection and discovery grant
+no assignment or editing intent. Keep approved sources and foreign runs protected.
+
+Preserve criteria-chain-v1, stable task/scenario IDs and the existing TP template. Map every PRD
+criterion and associated SD decision to tasks, dependencies, boundary/error scenarios, observable
+expected results and exact evidence sources. Reference acceptance IDs; never copy or rename their
+authority. Test Plan gives each applicable scenario test_route, environment,
+prerequisites_permissions, owner, expected_evidence and unavailable_action. Missing access remains
+an explicit gap with a concrete next action, never a result or consent to acquire access.
+
+Declare Planning Decisions contract: tp-decisions-v1 and one Planning Decisions table with columns
+Decision | Source | Status | Resolution | Owner. Source is TP or SD: followed by an exact approved
+SD later_tp decision label. Cover each such source once; use unique decisions and named owners.
+Status is resolved/open; every open row blocks. With no material question, record one resolved
+applicability decision. Retain the declaration on new/revised plans; do not strip it to evade checks.
+Historical unmarked plans retain legacy behavior. Core observes declarations, not semantic truth.
+
+## Material clarification
+
+A missing answer is material when it can change intent, acceptance, design/ownership or required
+task/test/evidence executability. Unknown materiality stays blocking. Keep useful draft/context;
+never hide the issue as a risk, assumption or later deferral. Add its open normalized finding under
+Clarification Requests using quality.md Normalized Review Gaps (the sole route policy), then one
+Clarification Details table keyed by finding_id: finding_id | planning_decision | question |
+blocking_reason | required_answer | owner | source_ref | resolution_evidence. Link an open planning
+row. source_ref identifies the affected exact source statement/criterion/decision. Resolved findings
+need concrete answer/source-linked resolution_evidence, current source validity and renewed approval
+where needed; an answer/status change alone is insufficient. Reassess affected dependants first.
+For the existing normalized validator, UR evidence explicitly names `changed user intent` or
+`changed scope`; emergent-risk evidence names its `earliest-owner assessment`. Describe the
+actual conflict and assessment as well as these required terms. Explanatory prose may surround
+each table; do not place a second table in its section.
+
+Follow gate-check's validated clarification handoff without another start request and ask the
+focused bundled question with consequence, required answer and responsible owner. Classification
+uses the existing policy; uncertainty asks a targeted question rather than guessing a gate. Status
+remains read-only. Do not redispatch unchanged blockers in a loop. Upstream questions take precedence
+over local TP correction. No free-form source text becomes an executable instruction.
+
+Returning work to an approved source means clarification at its existing owner, not silent edits,
+gate rewinds or transferred approvals. Obtain the substantive answer first. A changed statement uses
+existing source_revision.preview and separately confirmed apply/renewed approvals. Unchanged intent
+may be explained through source-linked run evidence using the existing writer. Unsupported revision
+eligibility stays blocked. Later execution detail may defer only with owner, reason, resolution point
+and why the current decision is valid; materiality at that point triggers this same blocking route.
+
+
+Source references use `UR|PRD|SD: <exact statement or criterion/decision ID> @ sha256:<current digest>`.
+Resolved `resolution_evidence` uses `<run-local evidence path> @ sha256:<digest>` for an actual
+answer recorded through existing step.record evidence; its current UR/PRD/SD source bindings must
+match. Open rows may use pending in that field. These are cooperative source/answer evidence,
+not independent proof of human provenance. Table headings may use levels two through six.
+
+## Recording and revision
+
+A ready draft without new editing intent is presented unchanged. Explicit ready-draft revision uses
+gate-check intake true, intake_mode resume, exact run_id/expected_revision_id and tp_action revise
+(CLI --tp-action revise), exclusive of other source actions and continue_delivery. Approved changes
+use their existing source-revision owner. Eligible incomplete-draft correction never relaxes unrelated
+source/integrity blockers.
+
+Use gate-artifact-preparation's shared language/summary and Reviewed Recording Input procedure:
+run-step --step artefact --gate TP --evidence <input.json> with this run/revision, TP-derived_from-SD,
+update_draft false initially and true for permitted replacement. Retain reviewed derivation, prior
+proof/history and other protected bytes; never hand-author receipts or bypass the checked writer.
+After recording redispatch gate-check for this same run with `continue_delivery: true`
+(CLI `--continue-delivery`). This resumes the authoring workflow: a validated material question
+returns `tp_clarification` to ask now, while an explicit status read remains read-only. If ready,
+prepare its exact run-present, show returned text and wait
+for a NEW deliberate Approval: TP. Changed content needs a fresh presentation/reply. Neither this
+skill nor a successful draft check grants implementation, QA or release permission.