[Feature]: Add an optional Autonomous Run Governance preset for end-to-end Spec Kit delivery

[hindermath]

Hi @mnriem, thank you again for your earlier guidance on publishing optional, stackable Spec Kit presets.

Background

Issue #2362 coordinated the earlier security, architecture, iSAQB, accessibility, cross-platform, and agent-parity governance presets. Those packages are deliberately focused on their own governance domains. This proposal is a separate optional preset for teams that explicitly delegate an entire Spec Kit feature run, including convergence, implementation, validation, and an authorized delivery closeout.

Problem Statement

Spec Kit provides strong individual commands, but a fully delegated run still needs a portable contract for phase ordering, repeated clarification and analysis, evidence-first execution, deterministic resume, remote permission boundaries, review convergence, non-recursive closeout, and workflow learning. Without that contract, projects tend to encode orchestration in one agent-specific prompt, infer remote authority too broadly, create self-invalidating evidence commits, or stop optional quality passes after an arbitrary number of iterations.

Field Validation

The preset was derived from six consecutive end-to-end field runs in hindermath/TuiVision:

Feature	Feature PR	Evidence closeout	Retrospective
018 Editor/Help/Resources Hardening	hindermath/TuiVision#42	#43	#44
019 Wave-3 Visual Porting	hindermath/TuiVision#45	#46	#47
020 Mouse Support and Interaction	hindermath/TuiVision#48	#49	#50
021 Terminal/Charset Hardening	hindermath/TuiVision#51	#52	N/A (no non-empty correction justified)
022 Wave-4 Visual Porting	hindermath/TuiVision#53	#54	#55
023 A11Y Framework	hindermath/TuiVision#56	#57	#58

The runs exposed and then validated exact delivery-evidence paths, bounded red-test matrices, compile-surface checks, linked-source identity boundaries, causal closeouts for self-invalidating reviewed-head facts, single-commit closeouts without self-reference, duplicate push/PR workflow classification, one mutable validation token per invocation, and fail-closed validation-helper handling.

Published Package

• Repository: https://github.com/hindermath/spec-kit-preset-autonomous-run-governance
• Release: https://github.com/hindermath/spec-kit-preset-autonomous-run-governance/releases/tag/v0.1.0
• Versioned ZIP: https://github.com/hindermath/spec-kit-preset-autonomous-run-governance/archive/refs/tags/v0.1.0.zip
• ZIP SHA-256 observed and reverified at release: ebece5bbc39a4e6ccb14f6cb933f55e4f8c20bdd7baeacca30a25fa292e78e36
• Requires GitHub Spec Kit >=0.8.3
• Recommended stack priority: 70

Installation:

specify preset add --from https://github.com/hindermath/spec-kit-preset-autonomous-run-governance/archive/refs/tags/v0.1.0.zip --priority 70

What the Preset Provides

• speckit.autonomous: orchestrates Specify, repeated Clarify, checklists, Plan, plan review, Tasks, repeated Analyze, Implement, validation, and an explicitly authorized closeout.
• speckit.autonomous-retrospective: classifies reusable learning as Promote, ObserveAgain, RejectProjectSpecific, Superseded, or NoPromotion.
• Constitution, Spec, Plan, Tasks, and standalone Agent addenda.
• Runbook, evidence ledger, retrospective, readiness checklist, and six-run field-validation templates.
• Agent command/skill generation tested for Codex, Claude, Copilot skills mode, and Antigravity (agy). Gemini CLI was additionally tested as a transitional and enterprise compatibility surface while it remains available through upstream Spec Kit.

Safety and Permission Boundaries

The preset is opt-in and does not execute anything merely by being installed. LocalImplementation is the safe default. PublishPR and MergeAndSync require explicit current user authority. General autonomy never grants remote write, merge, bypass, cancellation, secret, or provider-administration rights. Unavailable reviewers remain missing reviews, not approvals. Empty feature, retrospective, and closeout PRs are rejected. Any provider bypass remains a separate repository-specific policy decision and is not supplied by the preset.

Compatibility and Composition

The preset adds two new commands instead of replacing core commands. It appends governance to Constitution, Spec, Plan, and Tasks and provides a standalone agent addendum because Spec Kit 0.8.x has no core agent-file-template base layer. It was stacked successfully after the existing six governance presets at priorities 10, 20, 30, 40, 50, 60, and 70 without changing the six-preset matrix. It has no programming-language, test-framework, CI-provider, branch-version, agent-vendor, or merge-policy dependency.

Google's June 2026 transition changes the active Google validation target but not the provider-neutral preset boundary. For individual Free, Pro, and Ultra use, Antigravity (agy) is now the maintained target after 18 June 2026. Gemini CLI remains a transitional or enterprise, Cloud, and API compatibility surface while upstream Spec Kit continues to expose both integrations. The bounded TuiVision follow-up in hindermath/TuiVision#60 validates the real agy path, retains GEMINI.md and ~/.gemini/antigravity-cli/, and keeps historical Gemini evidence intact.

Validation Performed

• development install plus release-shaped local ZIP install
• public GitHub tag-ZIP download, checksum re-verification, and fresh install
• seven-preset list, info, and resolve composition
• remove, reinstall, disable, and enable lifecycle
• exactly one generated autonomous and retrospective surface for Codex, Claude, Copilot skills mode, and Antigravity (agy), plus the retained Gemini CLI transition/enterprise compatibility check
• synthetic remote-free LocalImplementation run through read-only Analyze: 3/3 requirements and 1/1 success criterion mapped, with zero Critical/High/Medium findings
• resume, convergence, no-empty-PR, and unauthorized remote-action refusal contracts
• Bash/macOS/Linux/Windows repository checks in the source package PR

Why This Belongs in the Community Catalog

This is optional workflow governance rather than a change to Spec Kit core behavior. It packages a repeated operational problem into a small stackable preset, keeps provider and project details out of core artifacts, and makes the permission model inspectable before users delegate long-running work. Catalog discovery would let teams evaluate and install it without implying that autonomous delivery is the default Spec Kit workflow.

Requested Maintainer Feedback

I would appreciate feedback on:

1. whether the package boundary is appropriately narrow for a community preset;
2. whether speckit.autonomous and speckit.autonomous-retrospective are suitable command names;
3. whether the permission metadata and LocalImplementation default are explicit enough;
4. whether the standalone agent addendum is the right 0.8.x composition approach; and
5. whether this package is suitable for a Community Catalog entry.

I will wait for maintainer guidance before preparing any catalog PR. This issue is a request for review and coordination, not a claim of automatic upstream inclusion.

Acceptance Criteria

• Maintainers confirm whether the preset scope is appropriate for Community Catalog discovery.
• Command names and metadata shape receive feedback or approval.
• Safety and permission boundaries are considered sufficiently explicit.
• Any requested package changes are tracked before a catalog PR.
• A catalog PR is opened only after maintainer guidance.

The external upstream decision is intentionally not a blocker for the locally published v0.1.0 package.

[hindermath]

Hi @mnriem, a short field-validation update after the original v0.1.0 publication.

TuiVision Feature 027 completed the mandatory pre-Wave-5 closure in PR #66. During its causal closeout, Linux and macOS CI found a portable validation-trigger gap: a Markdown gate changed from Blocked to Eligible, while an executable conformance test still consumed the old marker. Local documentation/A11Y checks had incorrectly classified the change as test-free.

I published the bounded patch as autonomous-run-governance v0.1.1. It adds one provider- and stack-neutral rule across the autonomous command, task shaping, runbook, readiness checklist, and agent addendum:

Before classifying documentation, status, schema, or evidence changes as test-free, search for executable validators that consume the changed paths, markers, schemas, or state values; update and run affected validators in the same slice.

The patch adds no script, dependency, implicit remote permission, or core Spec Kit behavior. LocalImplementation remains the safe default. The versioned GitHub ZIP installed successfully in a temporary Codex project with exactly one generated autonomous skill and one retrospective skill. SHA-256: 517e3b254617d8545ab26cb816290a402fd8c94a52c603ce74916e1d51844032.

I would appreciate any feedback on whether this validation-trigger rule is scoped appropriately for an optional community preset. No catalog PR is assumed or required from this update.

[hindermath]

One additional framing point from the six TuiVision field runs:

The primary benefit of an autonomous Spec Kit workflow is not "more lines per day." It is more independently verifiable work per complete quality cycle.

In this context, a complete quality cycle includes:

• specification and clarification to convergence;
• cross-artifact analysis before implementation;
• test-first implementation through real production paths;
• coverage, security, accessibility, documentation, and platform checks where applicable;
• explicit findings, residual risks, and follow-up boundaries;
• independent CI and review convergence;
• permission-bounded delivery and a non-recursive closeout;
• retrospective learning without silently expanding project or remote authority.

Delivery speed is useful as a secondary indicator, and the field runs did show higher and more stable delivery density. However, speed alone is not evidence of good software. A fast run that weakens tests, hides unresolved findings, bypasses review, or produces code that is difficult to maintain must still be considered unsuccessful.

This distinction is important to the preset's purpose: autonomous-run-governance is not intended as an "AI acceleration" shortcut. It standardizes the conditions under which delegated work remains inspectable, repeatable, reviewable, and safe to resume. The relevant optimization target is therefore quality-adjusted, evidence-backed throughput, not raw output volume.

I believe this is also a useful reason for keeping the preset optional and separate from Spec Kit core behavior: teams can explicitly adopt the stronger end-to-end governance contract when they delegate a complete run, without implying that autonomy or remote delivery should become the default.