create-agdf 0.12.0 → 0.13.0

package/generated/submissions/openai/agdf/meta/agdf-plugin.definition.json

@@ -0,0 +1,263 @@
+{
+  "schemaVersion": 1,
+  "id": "agdf",
+  "version": "0.13.0",
+  "displayName": "AI Governance & Delivery Framework",
+  "developerName": "Arndt Gold",
+  "description": "Control layer for governed AI-assisted delivery.",
+  "longDescription": "AI Governance & Delivery Framework (AGDF) is a governance framework for agentic work. Its first implementation provides a control layer for governed AI-assisted software delivery. It combines workflow skills, explicit gates, control templates and machine-readable repository checks to keep work aligned with approved scope and make evidence a prerequisite for consequential gate transitions. Supported workflows include brownfield analysis, task-plan review, QA decisions, durable run state and auditable delivery closeout. AGDF is an independent open-source project, not a security sandbox, compliance certification or autonomous release system.",
+  "homepage": "https://agdf.iself.eu",
+  "repository": "https://github.com/arndtgold/ai-native-governance-delivery-framework",
+  "license": "Apache-2.0",
+  "keywords": [
+    "agentic",
+    "governance",
+    "delivery",
+    "ai-native",
+    "brownfield"
+  ],
+  "category": "Productivity",
+  "brandColor": "#14B8A6",
+  "author": {
+    "name": "Arndt Gold",
+    "url": "https://agdf.iself.eu"
+  },
+  "codex": {
+    "skills": "./skills/",
+    "skillPrefix": "",
+    "agentRouter": "meta/agdf-agent-router.md",
+    "composerIcon": "./assets/agdf-icon.svg",
+    "logo": "./assets/agdf-logo.svg",
+    "capabilities": [
+      "Read",
+      "Write"
+    ],
+    "defaultPrompt": [
+      "Assess whether AGDF is proportionate for this repository and request before proposing any implementation. Explain AGDF's purpose and practical benefits, weigh governance overhead against the project's delivery risk, and recommend the lightest suitable path — or explicitly advise against AGDF where it would add more process than value.",
+      "Start this request under AGDF governance.",
+      "Create durable AGDF control state for this repository.",
+      "Close this delivery run with an auditable AGDF report."
+    ],
+    "hooks": "hooks/hooks.json"
+  },
+  "claude": {
+    "skillPrefix": "",
+    "agentRouter": "meta/agdf-agent-router.md",
+    "defaultPrompt": [
+      "Assess whether AGDF is proportionate for this repository and request before proposing any implementation. Explain AGDF's purpose and practical benefits, weigh governance overhead against the project's delivery risk, and recommend the lightest suitable path — or explicitly advise against AGDF where it would add more process than value.",
+      "Start this request under AGDF governance.",
+      "Create durable AGDF control state for this repository.",
+      "Close this delivery run with an auditable AGDF report."
+    ]
+  },
+  "copilot": {
+    "skillPrefix": "agdf-",
+    "runtimeContractFileName": "agdf-runtime-contract.md"
+  },
+  "opencode": {
+    "skillPrefix": "agdf-",
+    "globalSkillPrefix": "agdf-global-",
+    "evaluatorAgentName": "agdf-evaluator",
+    "runtimeContractFileName": "agdf-runtime-contract.md",
+    "instructionsFileName": "AGDF.md",
+    "npmPackage": "create-agdf",
+    "permissions": {
+      "question": "allow",
+      "edit": "ask",
+      "bash": "ask",
+      "skill": {
+        "agdf-*": "allow"
+      }
+    }
+  },
+  "interactions": {
+    "fallback": "exact_text",
+    "localeRegistry": "meta/agdf-interaction-locales.json",
+    "fallbackLocale": "en",
+    "optionOrder": [
+      "approve",
+      "revise",
+      "decline",
+      "cancel"
+    ],
+    "outcomes": [
+      "approve",
+      "revise",
+      "decline",
+      "cancel",
+      "no_response",
+      "timeout",
+      "empty",
+      "invalid",
+      "stale"
+    ],
+    "surfaces": {
+      "codex": {
+        "questionAdapter": "request_user_input",
+        "availability": "when_callable",
+        "gateSafety": "omit_auto_resolution",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline"
+        ],
+        "dismissOutcome": "cancel",
+        "approvalValueTransport": "exact_option_value",
+        "waitSafety": "deliberate_no_auto_resolution",
+        "authorizationPath": "exact_text",
+        "technicalPermissionOwner": "codex_host"
+      },
+      "claude": {
+        "questionAdapter": "AskUserQuestion",
+        "availability": "when_no_auto_continue_timeout",
+        "gateSafety": "no_timeout_or_hook_supplied_answer",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline"
+        ],
+        "dismissOutcome": "cancel",
+        "approvalValueTransport": "exact_option_value",
+        "waitSafety": "deliberate_no_auto_resolution",
+        "authorizationPath": "exact_text",
+        "technicalPermissionOwner": "claude_host"
+      },
+      "opencode": {
+        "questionAdapter": "question",
+        "availability": "when_permission_question_allows",
+        "gateSafety": "preserve_explicit_deny",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline"
+        ],
+        "dismissOutcome": "cancel",
+        "approvalValueTransport": "exact_option_value",
+        "waitSafety": "deliberate_no_auto_resolution",
+        "authorizationPath": "exact_text",
+        "technicalPermissionOwner": "opencode_host"
+      },
+      "fallback": {
+        "questionAdapter": "exact_text",
+        "availability": "always",
+        "gateSafety": "wait_for_deliberate_user_input",
+        "explicitOutcomes": [
+          "approve",
+          "revise",
+          "decline",
+          "cancel"
+        ],
+        "approvalValueTransport": "exact_option_value",
+        "waitSafety": "deliberate_no_auto_resolution",
+        "authorizationPath": "exact_text",
+        "technicalPermissionOwner": "host_specific"
+      }
+    }
+  },
+  "publicDistribution": {
+    "schemaVersion": 1,
+    "submissionType": "skills",
+    "technicalId": "agdf",
+    "publicDisplayName": "AGDF",
+    "fullDisplayName": "AI Governance & Delivery Framework (AGDF)",
+    "shortDescription": "Governed AI delivery controls",
+    "developerName": "Arndt Gold",
+    "publisher": {
+      "target": "Arndt Gold",
+      "verificationState": "unverified"
+    },
+    "category": "Productivity",
+    "urls": {
+      "website": "https://agdf.iself.eu",
+      "privacy": "https://agdf.iself.eu/privacy",
+      "terms": "https://agdf.iself.eu/terms",
+      "support": "https://agdf.iself.eu/support"
+    },
+    "defaultPrompt": [
+      "Assess whether AGDF fits this work and recommend the lightest safe delivery path.",
+      "Start this request under AGDF governance.",
+      "Review the active AGDF run and explain the next allowed step."
+    ],
+    "availability": {
+      "decisionState": "pending",
+      "countries": [],
+      "regions": [],
+      "workspaceContexts": [],
+      "decisionOwner": "verified publisher"
+    },
+    "submissionSources": {
+      "capabilityMatrix": "submission/openai/capability-matrix.json",
+      "reviewerCases": "submission/openai/reviewer-cases.json",
+      "releaseNotes": "submission/openai/release-notes.md",
+      "availabilityDecision": "submission/openai/availability.md"
+    }
+  },
+  "skillSet": [
+    {
+      "slug": "delivery-path-search",
+      "discovery": "optional",
+      "useFor": "high-impact planning decisions with several plausible next delivery steps before implementation",
+      "boundary": "read-only advisory search; never grants gate permission or replaces gate-check"
+    },
+    {
+      "slug": "brownfield-analysis",
+      "discovery": "automatic",
+      "useFor": "after gate-check permits Brownfield Review or implementation preparation, before non-trivial changes in existing systems",
+      "boundary": "clarifies reuse, owners, risks and Mode/Slice Decision; never bypasses gate-check; Brownfield Review is not implementation permission"
+    },
+    {
+      "slug": "ux-intent-definition",
+      "discovery": "automatic",
+      "useFor": "after approved UR and post-UR routing for medium/high UI/UX impact or ambiguous low-impact product semantics before PRD readiness",
+      "boundary": "non-authorizing analytical PRD input; never creates product intent, gate permission, technical design or a parallel product source of truth"
+    },
+    {
+      "slug": "clean-implementation-review",
+      "discovery": "automatic",
+      "useFor": "evidence dimension: inspect whether the solution is structurally clean",
+      "boundary": "supports Quality Readiness; not a TP or QA substitute"
+    },
+    {
+      "slug": "code-review",
+      "discovery": "automatic",
+      "useFor": "evidence dimension: review the actual diff for defects, regression and security findings",
+      "boundary": "supports Quality Readiness; does not replace QA"
+    },
+    {
+      "slug": "delivery-closeout",
+      "discovery": "automatic",
+      "useFor": "commit/PR-near handoff after QA/OR/UAT",
+      "boundary": "never performs VCS actions automatically"
+    },
+    {
+      "slug": "gate-check",
+      "discovery": "start_here",
+      "useFor": "new build/change intent, unclear approval, Structured Delivery, later-gate artefact requested",
+      "boundary": "does not create later artefacts or skip Mode/Slice Decision after Brownfield Review"
+    },
+    {
+      "slug": "qa-gate",
+      "discovery": "automatic",
+      "useFor": "sole final Quality Readiness decision",
+      "boundary": "only instance for `pass | revise | block`"
+    },
+    {
+      "slug": "release-or",
+      "discovery": "automatic",
+      "useFor": "auditable closeout for every relevant run",
+      "boundary": "not a QA substitute"
+    },
+    {
+      "slug": "task-plan-review",
+      "discovery": "automatic",
+      "useFor": "evidence dimension: verify whether the approved Task Plan was fulfilled",
+      "boundary": "supports Quality Readiness; no final QA decision"
+    }
+  ],
+  "marketplaces": {
+    "repository": {
+      "name": "agdf-repo",
+      "displayName": "This repository"
+    }
+  }
+}

package/generated/submissions/openai/agdf/meta/agdf-runtime-contract.md

@@ -0,0 +1,16 @@
+# AGDF Runtime Contract
+
+This manifest indexes the thematic runtime-contract modules used by AGDF skills and runtime validation.
+
+| Module | Path | Coverage |
+|---|---|---|
+| Task target resolution | `contracts/task-target-resolution.md` | Primary target authority, evidence/mutation separation, governance derivation, continuation and fail-closed target states |
+| Gate transitions | `contracts/gate-transition.md` | Source precedence, scope ambiguity, gate rules, Brownfield routing and transition model |
+| Interaction | `contracts/interaction.md` | Run Status Card, approval orientation, native interaction and locale contracts |
+| Modes | `contracts/modes.md` | Mode selection, Quick Task, Verified Change, trivial and bug boundaries |
+| Quality | `contracts/quality.md` | Quality readiness, chat discipline and quality output contracts |
+| Context Graph | `contracts/context-graph.md` | Knowledge persistence and Context Graph reconciliation |
+| Control scaffold | `contracts/control-scaffold.md` | Delivery Path Search, run state, CLI verification and Delivery Map |
+| Closeout | `contracts/closeout.md` | Support bridge, relevant-run boundary and non-duplication |
+
+The explanatory framework lives in `docs/`, the operating philosophy in `plugin/meta/agdf-constitution.md`, and the principles in `plugin/meta/agdf-tenets.md`.

package/generated/submissions/openai/agdf/meta/agdf-tenets.md

@@ -0,0 +1,201 @@
+AGDF Tenets
+===========
+
+The following are the **AGDF Tenets** — the guiding principles you *MUST*
+internalize for all AGDF-governed work. They are organized into **Generic
+Tenets**, which always apply, and **Operation-Specific Tenets**, which apply
+to particular kinds of operations.
+
+GENERIC TENETS
+--------------
+
+At any time and for all kinds of operations,
+you *MUST* honor the following **GENERIC TENETS**:
+
+-   **No Implementation Without Approved Product Contract**:
+    Implementation should not be based on vague intent.
+    A stable product contract defines accepted scope, acceptance criteria,
+    non-goals, constraints and success measurement.
+    For Structured Delivery or product-semantically relevant implementation,
+    no implementation may begin without an approved PRD or an explicitly
+    equivalent product contract.
+    Quick Task Mode may still handle narrow local fixes, reviews, debugging
+    and tooling maintenance when no new product meaning, user capability,
+    architecture, policy or persistence decision is introduced.
+
+    Verified Change may handle a bounded user-visible canonical metadata or
+    copy change only after approved UR and Brownfield Review when the Runtime
+    Contract record proves one owner, clean-at-baseline paths, no prohibited
+    impact and deterministic validation; every uncertainty escalates.
+
+-   **Fail Closed**:
+    When a necessary approval, input, or quality statement is missing,
+    the process must stop or demand revision.
+    The standard must never be "best effort" when the next step depends
+    on unverified assumptions.
+
+-   **One Authoritative Source for Product Intent**:
+    The product contract is the anchor for all downstream work.
+    Design, Task & Test Plan and implementation must not silently
+    reinterpret the agreed scope.
+
+-   **Design and Code Must Stay Separated**:
+    Conceptual design and implementation details should not be mixed
+    prematurely.
+    Design describes architecture, responsibilities, interfaces and flows.
+    Code describes executable behaviour, payloads, schemas, migrations
+    and implementation logic.
+
+-   **Tasks Need Business Justification**:
+    A task is not just a card on a board.
+    A task must make traceable which requirement, acceptance criterion,
+    design decision, risk or quality goal it addresses.
+    AI agents can produce convincing plans very quickly — work decomposition
+    must remain explainable and auditable.
+
+-   **Traceability Is Not Bureaucracy**:
+    Traceability does not mean producing as many documents as possible.
+    It means being able to answer fundamental delivery questions:
+    Why does this task exist? Which requirement supports this design decision?
+    Which acceptance criterion does this test check? Which approved artefact
+    permits this implementation? What changed between two versions?
+
+-   **Quality Needs Evidence**:
+    A quality claim is not sufficient.
+    The delivery should contain visible evidence: test results, build status,
+    review results, known limitations and remaining risks.
+    What was not checked must not be presented as if it were checked.
+
+-   **Changes Must Be Visible**:
+    When scope, acceptance criteria, non-goals or security, compliance or
+    data-protection aspects change, the change must be documented and reviewed.
+    Work with AI agents must not hide changes behind fluent conversation.
+
+-   **Think Before Acting**:
+    *Don't assume. Don't hide confusion. Surface trade-offs.*
+    Before implementing:
+    -   State your assumptions explicitly. If uncertain, ask.
+    -   If multiple interpretations exist, present them — don't pick silently.
+    -   If a simpler approach exists, say so. Push back when warranted.
+    -   If something is unclear, stop. Name what is confusing. Ask.
+
+-   **Surgical Changes**:
+    *Keep changes as small as possible — but as structurally sound as needed.*
+    -   Touch only what you must. Clean up only your own mess.
+    -   Don't "improve" adjacent code, comments, or formatting.
+    -   Match existing style, even if you'd do it differently.
+    -   The smallest technical diff is not automatically the best solution
+        if it creates state confusion, false ownership, or later rework.
+
+-   **Goal-Driven Execution**:
+    *Define success criteria. Loop until verified.*
+    Transform tasks into verifiable goals:
+    -   "Add validation" → "Write tests for invalid inputs, then make them pass"
+    -   "Fix the bug" → "Write a test that reproduces it, then make it pass"
+    -   "Refactor X" → "Ensure tests pass before and after"
+
+BROWNFIELD TENETS
+-----------------
+
+When working in an *existing system* (which is the normal case, not a special
+case), you *MUST* honor the following **BROWNFIELD TENETS**:
+
+-   **Brownfield First**:
+    Before any implementation, the existing codebase must be understood.
+    What is not visibly documented does not count as existing.
+
+-   **Reuse Before Create**:
+    Existing modules, services, components, endpoints, tests and
+    configurations are preferred over new creation, provided they can be
+    cleanly extended.
+
+-   **Minimal Clean Slice**:
+    The recommended change is the smallest clean and durably sound
+    intervention that fulfils the task plan.
+    A technically small diff is not automatically good if it creates
+    state confusion, false ownership, silent parallel structures or
+    later rework.
+
+-   **No Silent Parallel Structures**:
+    New artefacts with overlapping responsibility are to be avoided.
+    A new service, endpoint, wrapper or state owner may look clean locally
+    but create drift, parallel structures and later removal work systemically.
+
+-   **Existing Architecture Is Binding**:
+    Existing architecture, naming, error handling, logging, security and
+    test conventions are binding unless an explicit deviation is justified.
+
+-   **SoT/Runtime/Product-Semantics Drift Must Be Surfaced**:
+    If documented target architecture, observable runtime behaviour and
+    intended product semantics diverge, this must be explicitly flagged as
+    drift — not silently treated as a refactor.
+    In such cases, a UR or equivalent product-direction decision is needed
+    before implementation.
+
+-   **Primary Visible Ownership Must Be Checked**:
+    For visible chat, render, scroll, recovery or status problems,
+    check which existing path holds primary visible ownership.
+    Do not recommend a second render, scroll or recovery owner if the
+    existing system already has a suitable primary path.
+
+QUALITY CONTRACT TENETS
+-----------------------
+
+When *producing or reviewing* quality-contract outputs for agent runs,
+you *MUST* honor the following **QUALITY CONTRACT TENETS**:
+
+-   **Rule Before Outcome**:
+    A quality contract describes which rule applies and which evidence
+    proves it — not just whether the result looks plausible.
+
+-   **Agent Run, Not Just Result**:
+    Quality contracts check whether the agent worked on a sound foundation,
+    not just whether the output is functional.
+    "Wurde nach den vereinbarten Regeln gearbeitet?" is as important as
+    "Funktioniert es?"
+
+-   **No Evidence Replacement**:
+    Missing evidence may never be replaced by plausibility, assumptions
+    or fluent summaries.
+    A green build does not prove task completion.
+    Partial implementation must remain visible as partial.
+
+-   **Effect Must Be Visible**:
+    When a quality contract triggers, it must be visible whether the effect
+    is Stopp (block), Nacharbeit (revise) or Hinweis (warning).
+    There should be no silent ignoring.
+
+-   **Human Responsibility Remains**:
+    Quality contracts do not replace product requirements, gates, approvals
+    or human judgement.
+    They make visible what was checked, what evidence exists, and what
+    decision is still open.
+
+DELIVERY TENETS
+---------------
+
+When *closing a delivery run* with an orchestrierungsreport or delivery
+handoff, you *MUST* honor the following **DELIVERY TENETS**:
+
+-   **OR Is Always Mandatory**:
+    Every relevant run ends with an orchestrierungsreport (OR), even when
+    gates are blocking.
+    OR is an audit report, not a blocking gate.
+
+-   **No Leaks From Blocked Gates**:
+    The OR must not disclose content from artefacts that are not yet
+    allowed in the current gate.
+
+-   **Status, Not Sugarcoating**:
+    The OR is an audit and control report, not a marketing text.
+    Missing approvals, partial implementation, risks, fallbacks, brownfield
+    problems and open defects must be visible.
+
+-   **Next Step Must Be Operative**:
+    The OR ends with the immediate next permissible step and the exact
+    approval formula needed.
+
+-   **CD+Tests Is Not Completion**:
+    After CD+Tests, the OR reports only implementation and test status.
+    Without reviews, TP-coverage check and QA gate, formulations like
+    "fertig", "freigabefähig" or "delivery-ready" are not permitted.

package/generated/submissions/openai/agdf/meta/contracts/closeout.md

@@ -0,0 +1,29 @@
+# AGDF Runtime Contract — Closeout
+
+## Support Answer Bridge
+
+When the user asks about a concrete ticket, issue, incident or support question, end with exactly one smallest useful next step.
+Do not treat that next step as approval.
+When the next step is gated, name the required approval or AGDF skill instead of implying work may proceed.
+
+
+## Relevant Run
+
+A relevant run is any run that changes durable state, creates or updates an AGDF artefact, changes code or runtime behaviour, performs a gate decision, blocks on a governance condition, produces QA/UAT/release evidence, or closes a delivery slice.
+
+OR is not mandatory for a pure explanation, read-only inspection, small review, or local debugging step that produces no durable state change and no gate consequence.
+When in doubt, use a short OR-lite only if it clarifies gate state, evidence, risk, or the next permissible step.
+
+A `quick_task` fully inside the Non-Normative Trivial Change Boundary above stays exempt from the full
+selected-run ceremony even when it is otherwise a relevant run. If a selected canonical
+`RUN_STATE.md` currently reflects another scope, append exactly one line to that run's
+`Prior Run Pointers` section noting what changed and that it is unrelated; do not edit any other
+section or any other existing line.
+
+
+## Do Not Duplicate
+
+The explanatory framework lives in `docs/`.
+The operating philosophy lives in `plugin/meta/agdf-constitution.md`.
+The principles live in `plugin/meta/agdf-tenets.md`.
+This contract is only the compact runtime interface for skills.

package/generated/submissions/openai/agdf/meta/contracts/context-graph.md

@@ -0,0 +1,48 @@
+# AGDF Runtime Contract — Context Graph
+
+## Knowledge Persistence Decision
+
+Every relevant run should decide what happens to new durable knowledge.
+The decision is not a memory dump; it routes only reusable, evidenced information to the right owner.
+
+Use:
+
+- `memory_target: context_graph | sot_registry | scope_artifact | open_questions | none`
+- `memory_reason`: short reason for the target
+- `memory_refs`: paths or nodes affected
+
+Guidance:
+
+- Use `context_graph` for reusable Brownfield findings, decisions, risks, invariants and exit criteria.
+- Use `sot_registry` when source-of-truth ownership changes or drift is found.
+- Use `scope_artifact` for run-specific evidence, ticket details, screenshots, logs or local reproduction data.
+- Use `open_questions` when a durable question should survive the run but no answer is evidenced yet.
+- Use `none` for one-off observations without future decision value.
+
+
+## Context Graph Output
+
+When a run affects project memory or a Context Graph, use:
+
+- `Situation:` short plain-language summary when the impact is non-trivial
+- `context_graph_impact`: `none | link_only | update_existing_node | new_node_required | sot_drift`
+- `context_graph_refs`
+- `context_graph_reconciliation`: `resolved | not_applicable | open_gap`
+- `context_graph_required_action`: `none | link | update | create | resolve_drift`
+- `context_graph_gate_effect`: `none | warning | revise | block`
+- `context_graph_evidence`
+
+Do not create a new node for a mere version, a general chat summary, or a local observation without a concrete next clean step.
+`sot_drift` must not pass silently as a warning.
+
+### Context Graph Reconciliation
+
+Relevant-run closeout must reconcile Context Graph impact before presenting a clean delivery handoff.
+
+- Use `not_applicable` only when `context_graph_impact: none` and no durable graph knowledge is claimed.
+- Use `resolved` when required graph work is complete and concrete refs are present.
+- Use `open_gap` when graph work remains pending, refs are missing, or a node/update must still be curated.
+- `link`, `update`, `create` and `resolve_drift` require either `resolved` evidence or an explicit `open_gap`.
+- Resolved `link_only`, `update_existing_node` and `new_node_required` states require concrete `context_graph_refs`; `none`, empty refs or vague future-action language are not enough.
+- OR and delivery-closeout must not present commit-ready, release-ready or otherwise clean handoff while `context_graph_reconciliation: open_gap` remains.
+