create-agdf 0.12.0 → 0.13.1

package/generated/submissions/openai/agdf/skills/qa-gate/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: qa-gate
+description: Use this skill before any QA decision to determine whether implementation can be classified as pass, revise, or block based on TP coverage, Brownfield fit, solution integrity, evidence, and open blockers. Use it after CD+Tests, after reviews, and before UAT or release decisions.
+---
+
+# qa-gate
+
+## Purpose
+Make the formal QA gate decision.
+
+This skill is the only final QA decision point for `pass | revise | block`.
+
+It answers:
+
+- whether `QA pass` is allowed
+- whether the implementation must be revised
+- whether a hard blocker remains
+- whether relevant TP tasks are sufficiently verified
+- whether P0/P1 tasks are complete
+- whether Brownfield fit is sufficient
+- whether solution integrity is sufficient
+- whether blockers, critical risks, or missing evidence remain
+
+## Runtime Contract
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/quality.md`
+- `../../meta/contracts/context-graph.md`
+- `../../meta/contracts/gate-transition.md`
+
+QA-specific `decision` is exactly `pass | revise | block`.
+`pass` is allowed only when TP coverage, Brownfield fit, solution integrity, and relevant documentation/Context Graph impact are sufficiently evidenced.
+`sot_drift` must not pass silently as a warning.
+Consume applicable findings through `../../meta/contracts/quality.md` §Normalized Review Gaps.
+QA must not maintain a second mapping or reclassify review findings.
+
+When post-CD+Tests review evidence exists, present the Runtime Contract's derived Quality
+Readiness projection before the detailed QA report: Plan coverage, Solution integrity, Code
+quality and QA decision in that order. Name `qa-gate` as the sole decision owner, show one
+decisive reason and one permissible next action, and keep detailed reports as evidence links or
+on-demand detail. The projection is non-authorizing and must not replace the Run Status Card,
+Gate Transition Card or the durable QA report.
+
+## Rules
+1. No QA pass without strong evidence.
+2. TP is the reference, not merely working code.
+3. P0/P1 gaps block `pass`.
+4. Brownfield fit is mandatory.
+5. UI surface integrity is mandatory for UI-impacting changes.
+6. Solution integrity is mandatory.
+7. Always output exactly one decision: `pass`, `revise`, or `block`.
+8. Open risks, missing tests, partial TP coverage, or side effects must be visible.
+9. Applicable UX Intent Fidelity rows must all be `fulfilled` with suitable visible evidence before `pass`.
+10. A `requirements_gap` routes to PRD revision; QA must not invent or accept the missing criterion.
+11. Any applicable normalized finding that is `open`, missing, unknown, contradictory or supported by
+    insufficient evidence prevents `pass`.
+12. A `resolved` finding counts only when its durable review evidence proves the routed correction or decision.
+
+## When To Use
+- after `CD+Tests`
+- after `code-review`
+- after `task-plan-review`
+- after `clean-implementation-review`
+- before UAT
+- before any claim that implementation is done, releasable, or QA-ready
+- when evidence from Brownfield, TP, or clean-review skills exists
+
+Important:
+
+- `CD+Tests` is implementation and test status only.
+- Without review evidence and TP coverage, `QA pass` is not allowed.
+
+## Inputs
+Use what is available:
+
+- approved TP and TP Review
+- Brownfield Analysis
+- Clean Implementation Review
+- `code-review` or Code Review Report
+- test/build results
+- documentation impact review
+- runtime or UI evidence
+- known blockers and risks
+
+If evidence is missing, lower the decision accordingly.
+
+## Workflow
+1. Confirm the relevant gate context.
+2. Verify TP coverage.
+3. Verify P0/P1 completion.
+4. Verify Brownfield fit.
+5. Verify UX Intent Fidelity when applicable, including visible evidence for visible-behavior claims.
+6. Consume normalized findings without reclassification; fail closed on every open or invalid row.
+7. Verify solution integrity.
+8. Verify tests and evidence strength.
+9. Verify documentation and Context Graph impact if relevant.
+10. Decide:
+   - `pass`
+   - `revise`
+   - `block`
+11. State the single required next step.
+
+## Output
+Use this shape:
+
+```text
+## QA Gate
+- decision: pass | revise | block
+- evidence:
+- missing_evidence:
+- risks:
+- required_next_step:
+- impact_codes:
+```
+
+If Context Graph impact is relevant, include the fields from `../../meta/contracts/context-graph.md`.
+
+### Compact Chat Output
+
+At `pass`: one line — `QA: pass — <one-line summary>`. Reference the durable QA report
+path. Do not show the Quality Readiness projection or evidence inventory in chat.
+At `revise`/`block`: show the decisive dimension, reason and next action.
+
+## Decision Guidance
+- `pass`: required TP tasks are done, evidence is strong, no blocking Brownfield or solution-integrity risk remains.
+- `revise`: implementation is plausible but missing evidence, partial tasks, UX gaps, or fixable integrity issues remain.
+- `block`: hard prerequisite, approval, product semantics, security/compliance, SoT drift, or critical behaviour is unresolved.
+
+## Forbidden
+This skill must not:
+
+- grant QA pass from a green build alone
+- hide partial task completion
+- replace UAT
+- treat missing reviews as completed
+- downgrade SoT drift to harmless warning
+- silently repair, normalize or reroute a review finding

package/generated/submissions/openai/agdf/skills/qa-gate/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`qa-gate` - QA gate
+
+## SYNOPSIS
+
+`/qa-gate` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Makes the formal QA gate decision (`pass | revise | block`) based on TP coverage, Brownfield fit, solution integrity, evidence, and open blockers.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /qa-gate
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.

package/generated/submissions/openai/agdf/skills/release-or/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: release-or
+description: Use this skill at the end of every relevant run to produce a compact, auditable Orchestration Report. It summarizes gate status, delivered and intentionally not delivered work, TP coverage, Brownfield fit, solution integrity, open risks, and the next permissible step.
+---
+
+# release-or
+
+## Purpose
+Produce the Orchestration Report (OR) as the mandatory closeout for a relevant run.
+
+It reports:
+
+- current user gate
+- whether the run is `pass`, `revise`, `block`, or not yet QA-decided
+- what was delivered
+- what was intentionally not delivered
+- missing approvals
+- TP coverage status
+- Brownfield fit
+- solution integrity
+- documentation impact
+- Context Graph impact
+- open risks, blockers, retained fallbacks, and exit criteria
+- next permissible step
+- whether further quality follow-up or a separate delivery closeout is useful
+
+## Runtime Contract
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/closeout.md`
+- `../../meta/contracts/quality.md`
+- `../../meta/contracts/context-graph.md`
+- `../../meta/contracts/control-scaffold.md`
+
+OR-specific output must make gate status, delivered and intentionally not delivered content, missing approvals, missing evidence, risks, retained fallbacks, and the next permissible step visible.
+When `.agdf/control/` is present, persist or link the OR under `.agdf/control/artefacts/<key>/OR.md` and reference it from the selected canonical `RUN_STATE.md` or `MASTER_BACKLOG.md` when it is steering-relevant.
+Use the Runtime Contract definition of `Relevant Run` to decide whether OR is mandatory or whether a Quick Task mini-closeout is enough.
+
+## Rules
+1. OR is always allowed and mandatory for relevant runs as defined in the Runtime Contract.
+2. OR is an audit report, not a blocking gate.
+3. Do not leak artefacts from blocked later gates.
+4. Use OR-lite when early gates block.
+5. Use OR-full only within the allowed scope.
+6. Report status, not marketing language.
+7. Name missing approvals, partial implementation, risks, fallbacks, Brownfield issues, and open defects.
+8. Retained fallbacks require visible exit criteria and cleanup path.
+9. End with the immediately permissible next step.
+10. `CD+Tests` is not completion.
+11. When moving a backlog item to Completed or Superseded, use the canonical human-readable table and link the final OR with a document-relative Markdown link.
+12. For an executed `verified_change`, a lifecycle-consistent complete Mini-Closeout in the linked `VERIFIED_CHANGE.md` is the compact OR target; do not require a separate `OR.md` by ritual.
+13. Keep machine status normalization in the CLI; do not write internal snake_case status values into the human-facing backlog.
+14. Reconcile Context Graph impact before clean closeout: report `context_graph_reconciliation: resolved | not_applicable | open_gap`.
+15. If Context Graph work remains unresolved, report it as an explicit open gap and do not describe the run as cleanly handoff-ready.
+16. After writing or updating `MASTER_BACKLOG.md`, run `doctor --json` (or the locally available equivalent) and resolve any `AGDF_BACKLOG_STATUS_UNKNOWN` or `AGDF_BACKLOG_ARTEFACT_LABEL_UNKNOWN` finding before closeout. See the AGDF control scaffold's `MASTER_BACKLOG.md` template Rules section for the canonical status/artefact label vocabulary.
+
+## When To Use
+- at the end of every relevant run
+- after artefact creation
+- when a gate blocks
+- after `CD+Tests`
+- after `code-review`
+- after QA
+- after UAT
+- whenever a compact audit closeout is needed
+
+Do not force OR onto a pure explanation, read-only inspection, small review, or local debugging step that produces no durable state change and no gate consequence.
+
+## Inputs
+Use what is available:
+
+- current gate
+- existing approvals
+- artefacts created in this run
+- intentionally not delivered content
+- Task Plan
+- `task-plan-review`
+- `brownfield-analysis`
+- `clean-implementation-review`
+- `code-review`
+- QA Report
+- UAT Report
+- documentation impact review
+- Context Graph impact
+- known risks, defects, fallbacks, and open questions
+- test/build status and relevant metrics
+
+If information is missing, state the gap instead of guessing.
+
+## Workflow
+1. Determine the current gate and earliest blocker.
+2. Determine report depth:
+   - `OR-lite`: gate status, allowed/forbidden outputs, missing approval, next step
+   - `OR-full`: also delivered artefacts, TP coverage, Brownfield fit, solution integrity, risks, fallbacks, QA/UAT status
+3. Record the selected `Report mode` and durable OR target or link when `.agdf/control/` exists.
+4. Record delivered vs intentionally not delivered content.
+5. Summarize TP coverage if a TP exists.
+6. Summarize Brownfield fit and solution integrity if reviewed.
+7. Summarize tests and verification.
+8. Summarize documentation and Context Graph impact if relevant.
+9. Record Context Graph reconciliation as `resolved`, `not_applicable`, or `open_gap`.
+10. Name retained fallbacks and exit criteria.
+11. Set exactly one next permissible step.
+12. Set exactly one quality outlook.
+13. State whether `delivery-closeout` is the next operational handoff step when code changes exist and the delivery state allows it.
+
+## Output
+Use a compact structure:
+
+```text
+## OR
+- gate:
+- report_mode:
+- artefact:
+- status:
+- delivered:
+- intentionally_not_delivered:
+- evidence:
+- missing_evidence:
+- risks:
+- retained_fallbacks:
+- required_next_step:
+- quality_outlook:
+```
+
+When Context Graph impact is relevant, include the fields from `../../meta/contracts/context-graph.md`.
+Include `context_graph_reconciliation` whenever Context Graph impact is present. If the value is `open_gap`, required next step must resolve or explicitly retain that gap before commit-ready or release-ready handoff.
+
+## Forbidden
+This skill must not:
+
+- decide QA in place of `qa-gate`
+- call `CD+Tests` complete, QA-ready, or release-ready
+- hide missing approvals
+- provide later-gate content while an earlier gate blocks
+- produce the operative commit/PR handoff owned by `delivery-closeout`
+- execute commit, push, or PR actions

package/generated/submissions/openai/agdf/skills/release-or/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`release-or` - release OR
+
+## SYNOPSIS
+
+`/release-or` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Creates the mandatory Orchestration Report (OR) for a run. Summarizes gate status, delivered artefacts, TP coverage, Brownfield fit, solution integrity, open points, and the next permissible step.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /release-or
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.

package/generated/submissions/openai/agdf/skills/task-plan-review/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: task-plan-review
+description: Use this skill after code changes and before QA to verify whether the approved Task Plan was actually fulfilled. It checks each task_id against implementation, acceptance criteria, tests, visible evidence, and deviations, and provides TP coverage for QA.
+---
+
+# task-plan-review
+
+## Purpose
+Verify whether implementation actually satisfies the approved Task Plan.
+
+For each relevant task, this skill determines:
+
+- whether the task is fully, partially, or not completed
+- which acceptance criteria are done, partial, missing, or not verifiable
+- which files, tests, runtime evidence, or UI evidence support the finding
+- evidence strength
+- which gaps must be handed to `qa-gate`
+
+This skill provides TP coverage. It is not the final QA decision.
+
+## Runtime Contract
+Use these focused runtime-contract modules:
+
+- `../../meta/contracts/quality.md`
+- `../../meta/contracts/context-graph.md`
+- `../../meta/contracts/gate-transition.md`
+
+TP-specific output must evaluate every relevant `task_id` with completion status, AC coverage, evidence, missing evidence, and QA-relevant gaps.
+If `context_graph_required_action` is not `none`, the affected task is complete only if follow-up, evidence, or an intentionally open gap is visible.
+Applicable review gaps must use `../../meta/contracts/quality.md` §Normalized Review Gaps. This skill
+must not maintain its own type-to-route mapping.
+
+## Rules
+1. The Task Plan is the reference, not plausible code.
+2. No assumptions without evidence.
+3. Evaluate each relevant `task_id` individually.
+4. `fully_done` requires strong evidence.
+5. A green build alone does not prove TP completion.
+6. UI/state/render/recovery tasks need visible evidence, not only code.
+7. Partial implementation must be marked `partially_done`.
+8. P0/P1 gaps must be handed to QA.
+9. Out-of-scope changes must be reported.
+10. When evidence is unclear, fail closed to at least `partially_done`.
+11. When approved PRD UX criteria apply, verify both PRD-to-TP coverage and TP-to-code/surface fulfilment.
+12. Never invent a missing UX requirement. Report `requirements_gap` and route it to PRD revision.
+13. Visible behavior requires visible evidence; code evidence alone is `not_verifiable`.
+14. A fulfilled UX Intent Fidelity row uses `none`; every non-fulfilled applicable row uses one
+    normalized gap type and a contract-valid route.
+15. Missing, unknown or contradictory classifications fail closed and stay open.
+
+## Clarifications
+### TP Slice Before Target State
+If the TP explicitly defines a preparatory, additive, or limited slice, evaluate that exact scope.
+`fully_done` is allowed for a completed slice even if the larger target state remains open.
+
+### Missing Priorities
+If no priorities are defined, do not invent them. Mark the gap and treat QA relevance conservatively.
+
+### Missing Acceptance Criteria
+If ACs are unclear, derive only obvious expectations from title, goal, and scope. Mark AC basis as incomplete and lower evidence confidence as needed.
+
+## When To Use
+- after `CD+Tests`
+- before `QA`
+- when TP completion is unclear
+- when the user asks for TP fulfilment
+- when UI/state/runtime invariants are affected
+- when several agents or work steps touched the same TP
+
+## Inputs
+Use what is available:
+
+- Task Plan
+- `task_id`, `story_id`, priorities
+- acceptance criteria or success goals
+- changed files
+- tests and test results
+- build results
+- runtime/UI evidence
+- known deviations and scope decisions
+
+If TP or relevant tasks are missing, do not claim reliable TP coverage.
+
+## Output
+Use this compact structure:
+
+```text
+## TP Coverage
+| task_id | status | evidence | missing_evidence | QA impact |
+|---|---|---|---|---|
+
+## Summary
+- fully_done:
+- partially_done:
+- not_done:
+- out_of_scope_changes:
+- risks:
+- required_next_step:
+```
+
+When applicable, append:
+
+```text
+## UX Intent Fidelity
+| prd_criterion | working_mode_state | task_id | visible_evidence | fidelity_status | gap_type |
+|---|---|---|---|---|---|
+```
+
+Use `fulfilled | partial | missing | not_verifiable` for `fidelity_status` and
+the shared Quality Contract for `gap_type`. `none` is allowed only on a fulfilled row.
+
+When an applicable gap needs routing detail, append:
+
+```text
+## Normalized Findings
+| finding_id | gap_type | routing_target | gap_status | evidence | required_next_step |
+|---|---|---|---|---|---|
+```
+
+Use only contract-defined values. Do not reconstruct the type-to-route mapping locally.
+
+Completion status:
+
+- `fully_done`
+- `partially_done`
+- `not_done`
+
+AC status:
+
+- `done`
+- `partial`
+- `missing`
+- `not_verifiable`
+
+Evidence confidence:
+
+- `high`
+- `medium`
+- `low`
+
+### Compact Chat Output
+
+At `pass`: one line — `TP Review: pass — <X>/<total> tasks fully_done`.
+At `revise`/`block`: show incomplete tasks with missing evidence.
+
+## Forbidden
+This skill must not:
+
+- decide final QA
+- mark tasks fully done from code existence alone
+- hide partial work
+- upgrade missing evidence into confidence
+- reinterpret the TP scope
+- create or silently repair product requirements
+- treat code existence as visible UX evidence
+- emit `none` as a normalized finding type
+- silently repair or reclassify an invalid finding

package/generated/submissions/openai/agdf/skills/task-plan-review/help.md

@@ -0,0 +1,23 @@
+## NAME
+
+`task-plan-review` - task plan review
+
+## SYNOPSIS
+
+`/task-plan-review` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Checks after code changes and before QA whether the approved Task Plan tasks were fully, partially, or not completed. Provides reliable TP coverage as input for the QA gate decision.
+
+## EXAMPLES
+
+Trigger the skill:
+
+```text
+> /task-plan-review
+```
+
+## SEE ALSO
+
+See the full SKILL.md for detailed workflow, output format, and decision logic.

package/generated/submissions/openai/agdf/skills/ux-intent-definition/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: ux-intent-definition
+description: Use this skill after approved UR and post-UR routing when UI/UX impact is medium or high, or low with ambiguous product semantics, to define user intent, success, working modes, effective state, visible state ownership, activation, blockers, recovery and transitions as structured PRD input; fail closed when evidence or product decisions are unresolved. This internal analysis never grants gate permission or replaces the approved PRD.
+---
+
+# ux-intent-definition
+
+## Purpose
+
+Create structured, testable UX intent input before PRD approval so implementation reviews verify an
+approved product promise instead of inventing requirements after code exists.
+
+## Runtime Contract
+
+Use:
+
+- `../../meta/contracts/gate-transition.md` for impact routing, authority and revision behavior;
+- `../../meta/contracts/quality.md` for evidence and fail-closed output discipline.
+
+## Authority
+
+This is an internal analytical skill, not a user gate. It cannot approve artefacts, grant
+implementation permission, change approved UR/PRD intent, prescribe technical design or become a
+parallel product source of truth. Proposed criteria become authoritative only when incorporated into
+and approved as PRD content. Technical storage, derivation and component ownership remain SD concerns.
+
+## Inputs
+
+- approved UR and its intent, success signal, primary action and persona/context;
+- post-UR `delivery_context`, `ui_ux_impact`, reason and required flag;
+- existing behavior/ownership evidence for Brownfield work;
+- known working modes, state semantics, activation, blockers, recovery and transitions.
+
+## Workflow
+
+1. Confirm the approved UR and routing evidence. If required evidence is absent or conflicts, block.
+2. Identify the primary user intent, observable success and primary decision/action.
+3. For every relevant working mode, define effective state and visible state types.
+4. Separate `effective_state_authority_by_mode` from
+   `primary_state_presentation_owner_by_mode`; do not turn either into technical ownership.
+5. Define activation/deactivation, blockers with visible next actions, actionable recovery (including
+   visible retry for recoverable transient failure) and relevant state transitions.
+6. Propose observable PRD acceptance criteria and identify open product questions.
+7. Return exactly one decision: `ready | blocked | not_applicable`.
+
+## Decision Rules
+
+- `ready`: every required output is reliable enough for PRD drafting.
+- `blocked`: user intent, modes, effective state, authority, activation, blockers, recovery, transitions
+  or Brownfield evidence is missing, contradictory or materially ambiguous.
+- `not_applicable`: routing proves that no relevant user-facing intent, state or recovery behavior changes.
+
+A conflict with approved UR routes to UR revision. A material product change discovered after PRD
+approval routes to PRD revision, or UR revision when intent/scope changes. Never resolve the conflict
+silently. A required blocked result prevents PRD readiness.
+
+## Output
+
+Populate each field or use an explicit, justified `not_applicable`:
+
+```text
+- decision: ready | blocked | not_applicable
+- blocking_reason:
+- primary_user_intent:
+- success_signal:
+- primary_decision_or_action:
+- working_modes:
+- effective_state_by_mode:
+- visible_state_types:
+- effective_state_authority_by_mode:
+- primary_state_presentation_owner_by_mode:
+- activation_paths:
+- blockers:
+- recovery_paths:
+- relevant_state_transitions:
+- proposed_prd_acceptance_criteria:
+- open_product_questions:
+- affected_outputs:
+- evidence:
+- missing_evidence:
+- required_next_step:
+```
+
+For `blocked`, `blocking_reason`, `open_product_questions`, `affected_outputs`, `evidence`,
+`missing_evidence` and `required_next_step` are mandatory. When durable control state exists, write
+the result to `.agdf/control/artefacts/<key>/UX_INTENT_DEFINITION.md` without a Gate or approval field.
+
+## Forbidden
+
+- invent product intent or silently choose between conflicting modes/state authorities;
+- bypass UR/PRD revision or claim PRD readiness from a blocked result;
+- add a gate, approval value or implementation permission;
+- prescribe components, persistence, endpoints, styles or other technical design;
+- treat supporting analysis as authoritative beside the approved PRD.

package/generated/submissions/openai/agdf/skills/ux-intent-definition/help.md

@@ -0,0 +1,17 @@
+## NAME
+
+`ux-intent-definition` - define testable UX intent before PRD approval
+
+## SYNOPSIS
+
+`/ux-intent-definition` [`--help`|`-h`]
+
+## DESCRIPTION
+
+Produces structured `ready | blocked | not_applicable` PRD input for user intent, success, working
+modes, effective state, visible ownership, activation, blockers, recovery and transitions. It is an
+internal non-authorizing analysis and fails closed when product semantics or evidence are unresolved.
+
+## SEE ALSO
+
+See SKILL.md for triggers, authority, required fields and decision rules.

package/generated/submissions/openai/agdf/submission/openai/availability.md

@@ -0,0 +1,16 @@
+# Availability Decision Record
+
+- release: `0.13.1`
+- decision_state: `pending`
+- decision_owner: verified publisher
+- countries: not selected
+- regions: not selected
+- workspace_contexts: not selected
+
+Availability is deliberately not assumed to be global. Before submission, the verified publisher
+must select the supported countries, regions and workspace contexts in the OpenAI portal after
+confirming public legal routes and best-effort support capacity. The saved portal state must then be
+read back and reconciled with the canonical distribution record.
+
+This pending record blocks submission readiness but does not invalidate the deterministic repository
+candidate. Changing availability, submitting or publishing requires its own explicit authorization.

package/generated/submissions/openai/agdf/submission/openai/capability-matrix.json

@@ -0,0 +1,49 @@
+{
+  "schemaVersion": 1,
+  "releaseVersion": "0.13.1",
+  "evidenceStates": [
+    "common",
+    "codex-specific",
+    "chatgpt-specific",
+    "advisory",
+    "unavailable",
+    "unverified"
+  ],
+  "capabilities": [
+    {
+      "id": "proportional-fit",
+      "state": "common",
+      "description": "Assess whether AGDF is proportionate and recommend the lightest safe path.",
+      "evidenceClass": "repository",
+      "evidenceRef": "skills/gate-check/SKILL.md"
+    },
+    {
+      "id": "governed-repository-delivery",
+      "state": "codex-specific",
+      "description": "Use repository files, durable control state and local validation where the Codex host grants the required access.",
+      "evidenceClass": "unverified",
+      "evidenceRef": "PPD-L02"
+    },
+    {
+      "id": "codex-hooks",
+      "state": "codex-specific",
+      "description": "Lifecycle hooks are a Codex-specific enhancement and remain host-trust-dependent.",
+      "evidenceClass": "unverified",
+      "evidenceRef": "PPD-L02"
+    },
+    {
+      "id": "chatgpt-portable-skills",
+      "state": "advisory",
+      "description": "Fit assessment, explanation, planning and review may use the portable skills core; repository enforcement requires direct host evidence.",
+      "evidenceClass": "unverified",
+      "evidenceRef": "PPD-L03"
+    },
+    {
+      "id": "agdf-mcp-service",
+      "state": "unavailable",
+      "description": "The initial release provides no AGDF-operated MCP server, hosted account or service authentication.",
+      "evidenceClass": "bundle",
+      "evidenceRef": "candidate inventory"
+    }
+  ]
+}