ahmido
332f6325cb
Automated PR provided by Codex via Gitea API. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #483
101 lines
4.2 KiB
Markdown
101 lines
4.2 KiB
Markdown
---
|
|
name: tenantpilot-spec-readiness-gate
|
|
description: Validate an active TenantPilot Spec Kit package before implementation or merge-readiness claims.
|
|
---
|
|
|
|
## Purpose
|
|
|
|
Use this skill to check whether an active TenantPilot/TenantAtlas spec package is ready for implementation or review without inventing scope.
|
|
|
|
## Activate When
|
|
|
|
- Implementing an active or explicitly named spec.
|
|
- Reviewing `spec.md`, `plan.md`, and `tasks.md` for implementation readiness.
|
|
- A spec introduces new runtime behavior, tests, UI, persistence, abstractions, statuses, or workflow/tooling artifacts.
|
|
|
|
## Do Not Activate When
|
|
|
|
- The user asks for a simple code explanation with no implementation or readiness claim.
|
|
- The active work is a tiny non-spec maintenance task and the repo rules do not require Spec Kit artifacts.
|
|
- A completed historical spec is being read only as context.
|
|
|
|
## Maturity
|
|
|
|
L3 checklist.
|
|
|
|
## Gate Type
|
|
|
|
checklist.
|
|
|
|
## Source Evidence
|
|
|
|
- `AGENTS.md`
|
|
- `.specify/README.md`
|
|
- `.specify/memory/constitution.md`
|
|
- `.specify/memory/spec-approval-rubric.md`
|
|
- `.specify/templates/spec-template.md`
|
|
- `.specify/templates/plan-template.md`
|
|
- `.specify/templates/tasks-template.md`
|
|
- `docs/ai-coding-rules.md`
|
|
- `specs/416-tenantpilot-agent-skill-layer-v1/spec.md`
|
|
- `specs/416-tenantpilot-agent-skill-layer-v1/plan.md`
|
|
- `specs/416-tenantpilot-agent-skill-layer-v1/tasks.md`
|
|
|
|
## External Anchors
|
|
|
|
Not applicable.
|
|
|
|
## Required Repo Context
|
|
|
|
- Current branch and `git status --short`.
|
|
- Active spec directory.
|
|
- Active `spec.md`, `plan.md`, `tasks.md`, and checklist if present.
|
|
- Constitution and relevant `.specify/templates/`.
|
|
- Nearby related specs as read-only context.
|
|
- Code and tests named by the active plan.
|
|
|
|
## Execution Checklist
|
|
|
|
- Confirm exactly one active spec directory is in scope.
|
|
- Confirm required spec artifacts exist.
|
|
- Confirm the spec has problem, user value, functional requirements, non-goals, acceptance criteria, assumptions, risks, and open questions.
|
|
- Confirm the plan names affected repo surfaces and does not contradict architecture.
|
|
- Confirm tasks are ordered, bounded, verifiable, and include validation.
|
|
- Confirm Product Surface, RBAC, workspace/managed-environment scope, OperationRun, evidence, provider boundary, test governance, and proportionality sections are complete where relevant.
|
|
- Confirm completed specs are read-only context.
|
|
- Confirm dirty worktree entries are either active-spec artifacts or explicitly user-intended for this operation.
|
|
|
|
## Stop Conditions
|
|
|
|
- Active spec cannot be determined safely.
|
|
- `spec.md`, `plan.md`, or `tasks.md` is missing.
|
|
- Open questions block safe implementation.
|
|
- New persisted truth, abstraction, enum/status family, taxonomy, or framework lacks proportionality review.
|
|
- Runtime/UI changes are required but the spec says no runtime/UI impact.
|
|
- The implementation would rewrite completed specs or historical close-out evidence.
|
|
- Dirty unrelated work would be overwritten or mixed into the change.
|
|
|
|
## Required Evidence After Use
|
|
|
|
- Active spec path.
|
|
- Gate result: pass, pass with conditions, or fail.
|
|
- Blocking gaps or explicit statement that no blocking gaps remain.
|
|
- Exact files used as source evidence.
|
|
- Any residual risks with reason: out of scope, separate spec, existing unrelated debt, not reproducible, risky refactor, or blocked decision.
|
|
|
|
## Common Failure Modes
|
|
|
|
- Treating `.specify/spec.md` legacy content as the active feature spec.
|
|
- Filling missing scope from assumptions instead of stopping.
|
|
- Normalizing completed specs to satisfy newer templates.
|
|
- Letting a docs-only spec drift into runtime changes.
|
|
- Marking tasks complete before evidence exists.
|
|
|
|
## Quarantined Rules
|
|
|
|
Full Spec 416 quarantine list applies: `tenant_id` as platform-core ownership truth; Coverage v1 vocabulary as customer truth; v1-v2 adapters; fallback readers; dual writes; fallback-to-latest evidence; OperationRun as default customer proof; stale provider Healthy/Ready semantics; limited customer download vocabulary; raw provider/evidence payload default display; Product Surface runtime framework; historical audits as current truth.
|
|
|
|
## Review / Expiry
|
|
|
|
Review this skill whenever Spec Kit templates, the constitution, or the active Spec Kit workflow changes. No planned expiry.
|