docs: add Spec 305 readiness gate audit #360

Merged
ahmido merged 1 commits from 305-feature-readiness-gate-audit into platform-dev 2026-05-15 09:00:40 +00:00
5 changed files with 633 additions and 0 deletions

View File

@ -0,0 +1,57 @@
# Requirements Checklist: Feature Readiness Gate Audit
**Purpose**: Validate that Spec 305 remains a docs-only readiness gate and satisfies the user acceptance criteria.
**Created**: 2026-05-15
**Feature**: `specs/305-feature-readiness-gate-audit/spec.md`
## Spec Scope
- [x] Scope is documentation-only.
- [x] No runtime code changes are required or planned.
- [x] No migrations are required or planned.
- [x] No new UI surfaces are required or planned.
- [x] No tests are created or modified by this spec.
- [x] Specs 301-304 are treated as completed context and not reopened.
- [x] The roadmap is not rewritten.
- [x] Decision Register & Approval Workflow v1 is not specified or implemented here.
- [x] Legacy tenant panel compatibility is not reintroduced.
## Audit Artifact Requirements
- [x] `feature-readiness-audit.md` exists under `specs/305-feature-readiness-gate-audit/`.
- [x] The audit includes a repo-based matrix covering all 12 requested readiness areas.
- [x] Matrix statuses use only `ready`, `ready with caveat`, `blocker`, and `not applicable`.
- [x] Every blocker, if any, has a recommended action.
- [x] The audit explicitly evaluates whether Decision Register & Approval Workflow v1 may start as the next feature spec.
- [x] The audit documents a final `GO`, `GO WITH CONDITIONS`, or `NO-GO` recommendation.
## Evidence Requirements
- [x] Workspace/Admin Runtime readiness is assessed.
- [x] Environment-bound Surface readiness is assessed.
- [x] Legacy Route/Panel Retirement readiness is assessed.
- [x] Governance Feature Foundation readiness is assessed.
- [x] OperationRun Link/Execution Truth readiness is assessed.
- [x] Evidence/StoredReport Artifact Truth readiness is assessed.
- [x] Findings/Risk Acceptance readiness is assessed.
- [x] Review/Review Pack readiness is assessed.
- [x] RBAC/Capability readiness is assessed.
- [x] Audit/Event readiness is assessed.
- [x] Navigation/IA readiness is assessed.
- [x] Test Lane readiness is assessed.
## Validation Requirements
- [x] Focused Filament/navigation/legacy route tests from Specs 301-304 are run or explicitly recorded as skipped with reason.
- [x] Relevant Governance/Findings/Evidence/OpsUx tests are run or explicitly recorded as skipped with reason.
- [x] `git diff --check` is run.
- [x] `git status --short` confirms only `specs/305-feature-readiness-gate-audit/` changed.
- [x] Validation outcomes are copied into `feature-readiness-audit.md`.
## Quality Checks
- [x] Requirements are unambiguous and testable by document review.
- [x] No implementation detail mandates application changes.
- [x] Caveats are separated from blockers.
- [x] Stale product docs are treated as conditions, not as stronger truth than repo code/tests.
- [x] The next-feature recommendation distinguishes a fresh duplicate Decision Register spec from a legitimate follow-up or close-out path.

View File

@ -0,0 +1,104 @@
# Feature Readiness Audit
**Spec**: 305-feature-readiness-gate-audit
**Branch**: `305-feature-readiness-gate-audit`
**Audit date**: 2026-05-15
**Scope**: Docs-only repo audit after Specs 301-304
**Result**: GO WITH CONDITIONS
## Executive Recommendation
TenantPilot is ready to resume productization planning on top of the workspace-first `/admin` runtime, environment-bound routes, retired legacy tenant-panel posture, governance foundations, OperationRun links, evidence/report artifacts, findings/risk acceptance, reviews/review packs, RBAC/capabilities, audit/event foundations, and focused test lanes.
The next feature must not restart `Decision Register & Approval Workflow v1` as a fresh greenfield spec. Repo evidence shows Decision Register work already exists under Spec 265 with runtime pages, builders, navigation, and tests. The valid next step is either:
1. Close out and reconcile the existing Decision Register implementation and stale product docs, or
2. Start a narrowly named follow-up spec that builds on the implemented Decision Register truth without duplicating Spec 265.
The recommendation is **GO WITH CONDITIONS**:
- **Condition 1**: Do not create a duplicate fresh `Decision Register & Approval Workflow v1` spec. Treat existing Spec 265/runtime as current repo truth.
- **Condition 2**: Reconcile stale product queue docs before using them as the source for next-feature selection. `docs/product/implementation-ledger.md` and `docs/product/spec-candidates.md` still describe Decision Register as not implemented or only partly repo-real.
- **Condition 3**: Keep the next productization slice on canonical workspace/environment routes and do not reintroduce `/admin/t` or `/admin/tenants` compatibility.
- **Condition 4**: If the next slice changes artifact lifecycle, retention, export, or approval mutation behavior, split that into an explicit feature spec rather than bundling it into this gate.
## Readiness Matrix
| # | Readiness Area | Status | Repo Evidence | Caveat / Blocker | Recommended Action |
|---|---|---|---|---|---|
| 1 | Workspace/Admin Runtime Readiness | ready | `apps/platform/bootstrap/providers.php` registers `AdminPanelProvider` and `SystemPanelProvider`; `apps/platform/app/Providers/Filament/AdminPanelProvider.php` owns the `/admin` panel; Spec 304 records tenant-panel runtime dead-code retirement. | No runtime caveat found for next planning. | Start next work from the workspace-first `/admin` runtime. Keep provider registration in `bootstrap/providers.php` for Laravel 11+/12. |
| 2 | Environment-bound Surface Readiness | ready with caveat | Canonical environment routes exist under `/admin/workspaces/{workspace}/environments/{environment}`; `WorkspaceScopedTenantRoutes`, `ResolvesPanelTenantContext`, and `TenantOwnedModelFamilies` define the current tenant/environment surface posture; Specs 301-303 validated Inventory and Entra Groups cutovers. | Governance artifact proof is distributed across several resource/test families rather than one single route-audit proof. | For the next runtime feature, cite the exact resource/test family touched and keep deep links canonical under workspace/environment routes. |
| 3 | Legacy Route/Panel Retirement Readiness | ready | Specs 302 and 304 record no active `/admin/t` or `/admin/tenants` route families; route inspection returns no matching legacy routes; 304 added guard coverage for absent tenant panel runtime and legacy route rejection. | No blocker found. | Do not add compatibility aliases. Any next feature route must be canonical workspace/admin only. |
| 4 | Governance Feature Foundation Readiness | ready with caveat | `GovernanceInbox` and `DecisionRegister` pages exist; `GovernanceInboxSectionBuilder` and `GovernanceDecisionRegisterBuilder` exist; governance inbox and Decision Register tests exist under `tests/Feature/Governance` and `tests/Unit/Support/Governance*`. | Product docs drift: roadmap/candidate docs still frame Decision Register as future/partly implemented while runtime/tests exist. | Reconcile Decision Register docs or open a follow-up spec that explicitly builds on Spec 265, not a fresh v1 restart. |
| 5 | OperationRun Link/Execution Truth Readiness | ready | `operation_runs` schema includes workspace/environment/user/type/status/outcome/context and run identity fields; `OperationRunLinks` and `OperationRunUrl` centralize run URLs; Specs 301-304 validation included dashboard drill-through and high-signal link checks. | No blocker for read/link productization. New run-producing features still need normal OperationRun start UX review. | Reuse central OperationRun link/start contracts for any future run-producing work. |
| 6 | Evidence/StoredReport Artifact Truth Readiness | ready with caveat | `evidence_snapshots`, `evidence_snapshot_items`, `finding_exception_evidence_references`, and `stored_reports` schemas are workspace/environment scoped; EvidenceSnapshot and StoredReport resources exist; artifact/deep-link tests exist. | Artifact lifecycle, retention, export semantics, and customer-facing disclosure should not be assumed beyond current repo truth. | Use existing artifact links as evidence truth. Split lifecycle/export/retention productization into its own spec if needed. |
| 7 | Findings/Risk Acceptance Readiness | ready | Finding and FindingException resources exist; `finding_exceptions` and `finding_exception_decisions` support current decision state; Decision Register builder derives rows from FindingException decisions; findings/decision navigation and boundary tests exist. | No blocker for using findings/risk acceptance as existing foundation. | Next feature may build on existing risk acceptance truth, but should not duplicate Spec 265. |
| 8 | Review/Review Pack Readiness | ready with caveat | EnvironmentReview, CustomerReviewWorkspace, ReviewRegister, ReviewPack, and review-pack schemas/resources/tests exist; review pack rows carry workspace/environment, operation run, evidence snapshot, environment review, file metadata, and checksum fields. | Current readiness is strong for linking and evidence packaging; broader approval workflow semantics are not proven by this audit. | Treat reviews/review packs as supporting evidence surfaces unless the next spec explicitly changes approval workflow behavior. |
| 9 | RBAC/Capability Readiness | ready | Capabilities, capability resolvers, policies, workspace membership checks, and 404/403 expectations are covered by existing RBAC and resource authorization tests; governance pages include access checks. | No blocker found. | Next feature must declare capability requirements and preserve non-member 404 / missing-capability 403 semantics. |
| 10 | Audit/Event Readiness | ready | `AuditLog` model and audit recorder/logger support exist; audit tests exist for evidence, environment review, findings, and governance flows; sensitive flow specs require audit logging. | No blocker for next planning. | Any new mutation in the next feature must declare audit events and tests. This docs-only audit adds none. |
| 11 | Navigation/IA Readiness | ready with caveat | Admin panel navigation is workspace-first; environment navigation registration is guarded by `NavigationScope`; Specs 301 and 303 cut over Inventory and Directory/Entra Groups; Spec 304 validates retired tenant-panel links are absent. | Product queue docs are stale around Decision Register. Also, navigation readiness depends on continuing to avoid storage-object-first IA for approval flows. | Use workflow-first navigation for the next productization feature and reconcile stale docs before selecting from the product queue. |
| 12 | Test Lane Readiness | ready with caveat | Focused test families exist for Filament navigation/global search, legacy route retirement, governance inbox, Decision Register, findings, evidence, reviews, OperationRun links, RBAC, and audit. Browser smoke tests exist for Specs 301, 303, and 265. | This audit does not add tests. Validation should run focused confidence commands and record outcomes. | Run the focused validation commands in this artifact and keep browser reruns optional unless runtime UI changes occur. |
## Decision Register & Approval Workflow v1 Gate
**Fresh feature-spec decision**: NO-GO for starting a new greenfield `Decision Register & Approval Workflow v1` spec.
**Productization decision**: GO WITH CONDITIONS for a follow-up or close-out path that builds on existing repo truth.
Repo evidence indicates Decision Register is not merely a future candidate:
- `specs/265-decision-register-approval/` exists.
- `apps/platform/app/Filament/Pages/Governance/DecisionRegister.php` exists.
- `apps/platform/app/Support/GovernanceDecisions/GovernanceDecisionRegisterBuilder.php` exists.
- `apps/platform/app/Providers/Filament/AdminPanelProvider.php` registers the Decision Register page.
- Tests exist for Decision Register page access, authorization, builder behavior, finding exception navigation, decision summary, decision register boundaries, and browser smoke.
The blocker is not runtime readiness. The blocker is product-planning truth: a fresh v1 spec would duplicate implemented work and conflict with stale docs. The recommended action is to reconcile Spec 265 and product queue documentation first, then choose a follow-up with a precise scope, for example a close-out, approval-mutation hardening, or decision-register evidence/workflow extension.
## Blocker Register
| Blocker | Applies To | Recommended Action |
|---|---|---|
| Fresh `Decision Register & Approval Workflow v1` would duplicate existing Spec 265/runtime work. | Next feature-spec selection | Do not start a fresh v1. Reconcile existing docs and either close out Spec 265 or create a follow-up spec with a narrower new scope. |
| Product docs drift around Decision Register implementation state. | Next feature-spec selection | Update or explicitly annotate `docs/product/implementation-ledger.md` and `docs/product/spec-candidates.md` before using them as queue truth. |
No runtime blocker was found in Specs 301-304 readiness areas.
## Validation Plan and Results
Focused validation passed. Browser smoke tests were not rerun because this feature is docs-only and does not change rendered surfaces, routes, assets, or runtime behavior. Existing browser smoke coverage for Specs 301, 303, and 265 remains cited as readiness evidence.
| Validation | Command / Evidence | Result |
|---|---|---|
| Legacy route/panel retirement | `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/NoLegacyTenantPanelRuntimeTest.php tests/Feature/Guards/NoActiveTenantResourceRoutesTest.php tests/Feature/Workspaces/WorkspaceIntendedUrlLegacyRejectionTest.php` | passed: 20 tests, 42 assertions |
| Filament/navigation/global search from Specs 301-304 | `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/PanelNavigationSegregationTest.php tests/Feature/Filament/AdminTenantSurfaceParityTest.php tests/Feature/Filament/AdminSharedSurfacePanelParityTest.php tests/Feature/Filament/TenantOwnedResourceScopeParityTest.php tests/Feature/Filament/InventoryCoverageAdminTenantParityTest.php tests/Feature/Filament/EntraGroupAdminScopeTest.php tests/Feature/Filament/EntraGroupGlobalSearchScopeTest.php tests/Feature/Filament/PolicyResourceAdminSearchParityTest.php tests/Feature/Filament/PolicyVersionAdminSearchParityTest.php` | passed: 58 tests, 159 assertions |
| Governance/Decision/Findings | `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/GovernanceDecisions/GovernanceDecisionRegisterBuilderTest.php tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php tests/Feature/Governance/DecisionRegisterPageTest.php tests/Feature/Governance/DecisionRegisterAuthorizationTest.php tests/Feature/Governance/GovernanceInboxPageTest.php tests/Feature/Governance/GovernanceInboxAuthorizationTest.php tests/Feature/Findings/FindingExceptionDecisionRegisterNavigationTest.php tests/Feature/Findings/FindingExceptionDetailDecisionSummaryTest.php tests/Feature/Findings/FindingExceptionDecisionRegisterBoundariesTest.php` | passed: 27 tests, 137 assertions |
| Evidence/Reports/Reviews | `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Evidence/EvidenceSnapshotResourceTest.php tests/Feature/Evidence/EvidenceSnapshotAuditLogTest.php tests/Feature/EnvironmentReview/EnvironmentReviewAuditLogTest.php tests/Feature/EnvironmentReview/EnvironmentReviewRegisterTest.php tests/Feature/EnvironmentReview/EnvironmentReviewRegisterRbacTest.php tests/Feature/Reviews/CustomerReviewWorkspacePageTest.php tests/Feature/Reviews/CustomerReviewWorkspaceAuthorizationTest.php tests/Feature/Reviews/CustomerReviewWorkspacePackAccessTest.php tests/Feature/Reviews/CustomerReviewWorkspaceLaunchLinksTest.php tests/Feature/Filament/GovernanceArtifacts/GovernanceArtifactDeepLinkContractTest.php` | passed: 51 tests, 362 assertions |
| OperationRun links and legacy route regressions | `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php tests/Feature/Operations/LegacyRunRoutesNotFoundTest.php tests/Feature/ProviderConnections/LegacyRedirectTest.php tests/Feature/RequiredPermissions/RequiredPermissionsLegacyRouteTest.php tests/Feature/Guards/ManagedEnvironmentCanonicalRouteContractTest.php tests/Feature/Filament/PolicyVersionResolvedReferenceLinksTest.php` | passed: 15 tests, 98 assertions |
| Combined implementation-loop gate rerun | `cd apps/platform && ./vendor/bin/sail artisan test --compact` with the focused files listed above | passed: 171 tests, 798 assertions |
| Diff whitespace | `git diff --check` | passed: no output |
| New-file whitespace scan | `rg -n "[[:blank:]]+$" specs/305-feature-readiness-gate-audit || true` | passed after removing Markdown trailing spaces |
| Scope check | `git status --short --branch` | passed: only `?? specs/305-feature-readiness-gate-audit/` |
## No-Change Confirmation
This audit does not change:
- Application runtime code
- Database migrations
- Factories, seeders, or fixtures
- Tests
- Filament resources/pages/widgets
- Routes
- Navigation registration
- Global search behavior
- OperationRun behavior
- RBAC/capability logic
- Audit/event behavior
- Product roadmap content
## Final Gate
**Overall recommendation**: GO WITH CONDITIONS.
TenantPilot can proceed toward the next productization effort after Specs 301-304, but the next effort should not be a fresh Decision Register v1. The repo is ready for a bounded follow-up once stale product docs are reconciled and the follow-up explicitly builds on existing Decision Register, governance, findings, evidence, reviews, RBAC, audit, navigation, and OperationRun foundations.

View File

@ -0,0 +1,186 @@
# Implementation Plan: Feature Readiness Gate Audit
**Branch**: `305-feature-readiness-gate-audit` | **Date**: 2026-05-15 | **Spec**: `specs/305-feature-readiness-gate-audit/spec.md`
**Input**: Feature specification from `/specs/305-feature-readiness-gate-audit/spec.md`
## Summary
Create a docs-only readiness gate for TenantPilot after Specs 301-304. The implementation is repository inspection plus one audit artifact that decides whether the next productization feature, likely Decision Register & Approval Workflow v1, may start. No application runtime, migrations, tests, routes, UI, or roadmap content will be changed.
## Technical Context
**Language/Version**: PHP 8.4.15, Laravel 12.52.0, Filament 5.2.1, Livewire 4.1.4
**Primary Dependencies**: Laravel, Filament v5, Livewire v4, Pest 4, PostgreSQL via Sail
**Storage**: N/A for this feature; existing PostgreSQL schema is read only for audit evidence
**Testing**: Existing Pest feature/unit/browser tests only; no new tests
**Validation Lanes**: confidence via focused feature/unit tests; browser tests cited where existing and relevant; `git diff --check`
**Target Platform**: Laravel Sail local development, Dokploy container deployment for staging/production unchanged
**Project Type**: Laravel monolith under `apps/platform` plus docs/spec artifacts
**Performance Goals**: N/A - docs-only
**Constraints**: No runtime code changes, no migrations, no test edits, no UI surfaces, no Decision Register feature work
**Scale/Scope**: One readiness gate over 12 requested audit areas
## UI / Surface Guardrail Plan
- **Guardrail scope**: no operator-facing surface change.
- **Native vs custom classification summary**: N/A.
- **Shared-family relevance**: audit references navigation, governance, evidence, reviews, RBAC, audit, and OperationRun links as existing families only.
- **State layers in scope**: none.
- **Audience modes in scope**: N/A.
- **Decision/diagnostic/raw hierarchy plan**: N/A.
- **Raw/support gating plan**: N/A.
- **One-primary-action / duplicate-truth control**: The audit prevents duplicate next-feature truth by distinguishing existing Decision Register runtime from a legitimate follow-up spec.
- **Handling modes by drift class or surface**: Stale roadmap/spec-candidate truth is recorded as a condition, not silently rewritten.
- **Repository-signal treatment**: review-mandatory.
- **Special surface test profiles**: global-context-shell, standard-native-filament, shared-detail-family, monitoring-state-page evidence only.
- **Required tests or manual smoke**: focused feature/unit validation. No new browser smoke required for docs-only changes.
- **Exception path and spread control**: none.
- **Active feature PR close-out entry**: Guardrail.
## Shared Pattern & System Fit
- **Cross-cutting feature marker**: yes, audit-only.
- **Systems touched**: Spec Kit docs under `specs/305-feature-readiness-gate-audit/`.
- **Shared abstractions reused**: No runtime reuse. Evidence can reference existing runtime abstractions such as `WorkspaceScopedTenantRoutes`, `ScopesGlobalSearchToTenant`, `OperationRunLinks`, governance builders, policy/capability helpers, and audit recorders.
- **New abstraction introduced? why?**: none.
- **Why the existing abstraction was sufficient or insufficient**: Existing repo structures provide enough evidence for a readiness decision.
- **Bounded deviation / spread control**: The only output beyond standard Spec Kit files is `feature-readiness-audit.md`.
## OperationRun UX Impact
- **Touches OperationRun start/completion/link UX?**: no.
- **Central contract reused**: N/A.
- **Delegated UX behaviors**: N/A.
- **Surface-owned behavior kept local**: none.
- **Queued DB-notification policy**: N/A.
- **Terminal notification path**: N/A.
- **Exception path**: none.
## Provider Boundary & Portability Fit
- **Shared provider/platform boundary touched?**: no.
- **Provider-owned seams**: N/A.
- **Platform-core seams**: N/A.
- **Neutral platform terms / contracts preserved**: Existing terms remain unchanged.
- **Retained provider-specific semantics and why**: none.
- **Bounded extraction or follow-up path**: none.
## Constitution Check
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
- Inventory-first: pass. The audit distinguishes current repo evidence from roadmap/spec-candidate intent.
- Read/write separation: pass. No writes to runtime data or external systems.
- Graph contract path: N/A. No Graph calls or contracts changed.
- Deterministic capabilities: pass. Existing capability/RBAC tests may be cited; no capability logic changed.
- RBAC-UX: pass. The audit verifies admin/system separation, workspace isolation, global search posture, and retired tenant-panel routes as evidence.
- Workspace isolation: pass. The audit checks workspace-first admin runtime and environment-bound surfaces.
- Destructive-like actions require confirmation: pass. No actions changed; existing destructive action posture is evidence only.
- Tenant isolation: pass. No runtime reads/writes changed.
- Run observability: pass. No new `OperationRun` creation; existing link/execution truth is audited.
- OperationRun start UX: pass. No start/link semantics are changed.
- Ops-UX lifecycle: pass. No lifecycle code changed.
- Ops-UX summary counts: pass. No summary counts changed.
- Ops-UX guards: pass. Existing guard tests are used where relevant.
- Automation: N/A.
- Data minimization: pass. No data storage/logging changes.
- Test governance (TEST-GOV-001): pass. The spec records the focused validation lane without adding tests.
- Proportionality (PROP-001): pass. Documentation artifact only; no runtime structure.
- No premature abstraction (ABSTR-001): pass. No new abstractions.
- Persisted truth (PERSIST-001): pass. No persisted runtime truth.
- Behavioral state (STATE-001): pass. No new states.
- UI semantics (UI-SEM-001): pass. No UI semantics changed.
- Shared pattern first (XCUT-001): pass. Audit references existing shared paths only.
- Provider boundary (PROV-001): pass. No provider boundary changes.
- V1 explicitness / few layers (V1-EXP-001, LAYER-001): pass. One docs artifact.
- Spec discipline / bloat check (SPEC-DISC-001, BLOAT-001): pass. Scope is limited to the readiness gate.
- Badge semantics (BADGE-001): N/A.
- Filament-native UI (UI-FIL-001): pass. No Filament UI changes.
- UI/UX surface taxonomy (UI-CONST-001 / UI-SURF-001): N/A.
- Decision-first operating model (DECIDE-001): pass. The audit itself gates a product decision; no operator surface changes.
- Audience-aware disclosure (DECIDE-AUD-001 / OPSURF-001): N/A.
- UI/UX inspect model (UI-HARD-001): N/A.
- UI/UX action hierarchy (UI-HARD-001 / UI-EX-001): N/A.
- UI/UX scope, truth, and naming (UI-HARD-001 / UI-NAMING-001 / OPSURF-001): pass. No naming changes.
- UI/UX placeholder ban (UI-HARD-001): N/A.
- UI naming (UI-NAMING-001): N/A.
- Operator surfaces (OPSURF-001): pass. No operator surface changes.
- Filament UI Action Surface Contract: pass. No Filament Resource/RelationManager/Page changes.
- Filament UI UX-001 (Layout & IA): N/A.
- Action-surface discipline (ACTSURF-001 / HDR-001): N/A.
- UI review workflow: pass. Guardrail classification is explicit and not duplicated into runtime work.
## Test Governance Check
- **Test purpose / classification by changed surface**: N/A for changed files; existing focused tests are used as readiness evidence.
- **Affected validation lanes**: confidence via existing feature/unit tests; browser lane is not required for a docs-only diff.
- **Why this lane mix is the narrowest sufficient proof**: The artifact changes only documentation. Focused tests prove the repo foundations being audited are currently green where practical.
- **Narrowest proving command(s)**:
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/NoLegacyTenantPanelRuntimeTest.php tests/Feature/Guards/NoActiveTenantResourceRoutesTest.php tests/Feature/Workspaces/WorkspaceIntendedUrlLegacyRejectionTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/PanelNavigationSegregationTest.php tests/Feature/Filament/AdminTenantSurfaceParityTest.php tests/Feature/Filament/AdminSharedSurfacePanelParityTest.php tests/Feature/Filament/TenantOwnedResourceScopeParityTest.php tests/Feature/Filament/InventoryCoverageAdminTenantParityTest.php tests/Feature/Filament/EntraGroupAdminScopeTest.php tests/Feature/Filament/EntraGroupGlobalSearchScopeTest.php tests/Feature/Filament/PolicyResourceAdminSearchParityTest.php tests/Feature/Filament/PolicyVersionAdminSearchParityTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/GovernanceDecisions/GovernanceDecisionRegisterBuilderTest.php tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php tests/Feature/Governance/DecisionRegisterPageTest.php tests/Feature/Governance/DecisionRegisterAuthorizationTest.php tests/Feature/Governance/GovernanceInboxPageTest.php tests/Feature/Governance/GovernanceInboxAuthorizationTest.php tests/Feature/Findings/FindingExceptionDecisionRegisterNavigationTest.php tests/Feature/Findings/FindingExceptionDetailDecisionSummaryTest.php tests/Feature/Findings/FindingExceptionDecisionRegisterBoundariesTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Evidence/EvidenceSnapshotResourceTest.php tests/Feature/Evidence/EvidenceSnapshotAuditLogTest.php tests/Feature/EnvironmentReview/EnvironmentReviewAuditLogTest.php tests/Feature/EnvironmentReview/EnvironmentReviewRegisterTest.php tests/Feature/EnvironmentReview/EnvironmentReviewRegisterRbacTest.php tests/Feature/Reviews/CustomerReviewWorkspacePageTest.php tests/Feature/Reviews/CustomerReviewWorkspaceAuthorizationTest.php tests/Feature/Reviews/CustomerReviewWorkspacePackAccessTest.php tests/Feature/Reviews/CustomerReviewWorkspaceLaunchLinksTest.php tests/Feature/Filament/GovernanceArtifacts/GovernanceArtifactDeepLinkContractTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php tests/Feature/Operations/LegacyRunRoutesNotFoundTest.php tests/Feature/ProviderConnections/LegacyRedirectTest.php tests/Feature/RequiredPermissions/RequiredPermissionsLegacyRouteTest.php tests/Feature/Guards/ManagedEnvironmentCanonicalRouteContractTest.php tests/Feature/Filament/PolicyVersionResolvedReferenceLinksTest.php`
- `git diff --check`
- **Fixture / helper / factory / seed / context cost risks**: none.
- **Expensive defaults or shared helper growth introduced?**: no.
- **Heavy-family additions, promotions, or visibility changes**: none.
- **Surface-class relief / special coverage rule**: N/A.
- **Closing validation and reviewer handoff**: Confirm tests were run or explicitly recorded as skipped with reason; confirm `git status --short` stays under `specs/305-feature-readiness-gate-audit/`.
- **Budget / baseline / trend follow-up**: none.
- **Review-stop questions**: Does the audit accidentally start a feature spec, change application code, or treat stale docs as stronger than repo truth?
- **Escalation path**: document-in-feature if validation exposes an existing blocker.
- **Active feature PR close-out entry**: Guardrail.
- **Why no dedicated follow-up spec is needed**: This is the dedicated readiness gate requested by the user.
## Filament v5 Output Contract
- **Livewire v4.0+ compliance**: The installed runtime is Livewire 4.1.4 with Filament 5.2.1; this feature makes no runtime changes and introduces no Livewire v3 references.
- **Provider registration location**: Existing panel providers remain registered in `apps/platform/bootstrap/providers.php`. This feature does not modify provider registration.
- **Globally searchable resources**: Existing audited posture only. `EntraGroupResource` is globally searchable and has a View page. `InventoryItemResource` has a View page. Policy, PolicyVersion, FindingException, EvidenceSnapshot, EnvironmentReview, ReviewPack, and StoredReport surfaces are disabled for global search or remain non-global-search evidence as recorded in the audit.
- **Destructive actions**: None introduced or changed. Existing destructive actions remain outside this docs-only diff; confirmation and authorization are validated only through existing tests/resource inspection.
- **Asset strategy**: No assets added or changed. Existing deployment posture for Filament assets remains unchanged; deploys that publish registered Filament assets still run `cd apps/platform && php artisan filament:assets`.
- **Testing plan**: Existing focused Filament/navigation, governance, findings, evidence, review, OperationRun/route-retirement, and `git diff --check` validations are listed above. No Livewire tests are added or modified.
## Project Structure
### Documentation (this feature)
```text
specs/305-feature-readiness-gate-audit/
|-- checklists/
| `-- requirements.md
|-- feature-readiness-audit.md
|-- plan.md
|-- spec.md
`-- tasks.md
```
### Source Code (repository root)
```text
apps/platform/
`-- unchanged
specs/301-admin-inventory-navigation-cutover/
specs/302-tenant-owned-surface-route-audit/
specs/303-admin-directory-groups-cutover/
specs/304-tenant-panel-dead-code-retirement/
`-- read-only evidence
```
**Structure Decision**: Documentation-only Spec Kit artifact under `specs/305-feature-readiness-gate-audit/`; no source code structure changes.
## Complexity Tracking
| Violation | Why Needed | Simpler Alternative Rejected Because |
|---|---|---|
| None | N/A | N/A |
## Phase Plan
1. **Audit prep**: Read Constitution, roadmap/spec candidates, Specs 301-304, related close-out notes, and relevant runtime/test evidence.
2. **Evidence collection**: Inspect route/provider state, resource/global-search posture, governance/finding/evidence/review/OperationRun/RBAC/audit foundations, and existing tests.
3. **Artifact creation**: Write `feature-readiness-audit.md` with the required readiness matrix, blocker actions, validation evidence, and next-feature recommendation.
4. **Validation**: Run focused tests where practical and `git diff --check`.
5. **Close-out**: Confirm only spec artifacts changed and summarize GO / GO WITH CONDITIONS / NO-GO.

View File

@ -0,0 +1,226 @@
# Feature Specification: Feature Readiness Gate Audit
**Feature Branch**: `305-feature-readiness-gate-audit`
**Created**: 2026-05-15
**Status**: Ready for docs-only audit
**Input**: User description: "Create the next spec as 305-feature-readiness-gate-audit. Docs-only audit whether TenantPilot after Specs 301-304 is ready to restart the first real productization feature, likely Decision Register & Approval Workflow v1."
## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
- **Problem**: Specs 301-304 changed the admin runtime, workspace/environment surface model, legacy tenant-panel posture, and navigation assumptions. Before starting the next productization feature, the repo needs a grounded readiness gate rather than relying on roadmap intent.
- **Today's failure**: Without this audit, the next feature spec can accidentally duplicate already implemented Decision Register work, depend on stale product docs, or reintroduce assumptions from the retired legacy tenant panel.
- **User-visible improvement**: Productization planning gets a clear GO / GO WITH CONDITIONS / NO-GO signal backed by repo evidence, with blockers and recommended actions called out before feature work starts.
- **Smallest enterprise-capable version**: A docs-only readiness artifact that reviews the 12 requested areas, records evidence paths, marks readiness with the required status set, and explicitly evaluates whether Decision Register & Approval Workflow v1 may start as the next feature spec.
- **Explicit non-goals**: No runtime code changes, migrations, new UI surfaces, tests changes, broad refactors, roadmap rewrite, legacy compatibility restoration, or Decision Register feature specification/implementation.
- **Permanent complexity imported**: One docs artifact (`feature-readiness-audit.md`) plus this spec, plan, tasks, and requirements checklist. No new runtime model, enum, service, status family, route, UI concept, or test family.
- **Why now**: The repo just completed foundation and retirement specs 301-304; the next feature should only start once workspace-first admin runtime, route retirement, governance foundations, evidence, findings, reviews, RBAC, audit, navigation, and test lanes are confirmed feature-ready.
- **Why not local**: A local note would not create an auditable Spec Kit gate, would not force the Decision Register duplication check, and would not preserve the evidence trail for the next feature candidate.
- **Approval class**: Cleanup.
- **Red flags triggered**: Potential duplicate feature work, stale roadmap/spec-candidate truth, and broad cross-surface audit scope. These are handled by keeping the output docs-only, bounded to repo evidence, and explicitly forbidding runtime changes.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 12/12**
- **Decision**: approve.
## Spec Scope Fields *(mandatory)*
- **Scope**: canonical-view.
- **Primary Routes**: No route changes. Audit evidence includes `/admin`, `/admin/workspaces/{workspace}`, `/admin/workspaces/{workspace}/environments/{environment}`, OperationRun detail links, governance pages, evidence/report/review resources, and retired legacy route families.
- **Data Ownership**: No data changes. Audit references existing workspace-owned and tenant/environment-owned records only.
- **RBAC**: No RBAC change. Audit verifies repo evidence for workspace membership, capabilities, 404/403 behavior, and audit/event foundations.
For canonical-view specs:
- **Default filter behavior when tenant-context is active**: N/A - no runtime query or page behavior changes.
- **Explicit entitlement checks preventing cross-tenant leakage**: N/A - audit-only. Existing tests and resource traits are reviewed as evidence.
## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
- **Cross-cutting feature?**: yes, audit-only.
- **Interaction class(es)**: navigation, routing, global search, OperationRun links, governance inbox, findings, evidence/report viewers, review packs, RBAC, audit/event foundations, and test lanes.
- **Systems touched**: Documentation only under `specs/305-feature-readiness-gate-audit/`.
- **Existing pattern(s) to extend**: Spec Kit spec/plan/tasks/checklist workflow and repo-local feature audit artifacts.
- **Shared contract / presenter / builder / renderer to reuse**: No runtime shared contract is changed. Audit evidence may cite `WorkspaceScopedTenantRoutes`, `ScopesGlobalSearchToTenant`, `OperationRunLinks`, governance builders, policies, capabilities, and audit log support.
- **Why the existing shared path is sufficient or insufficient**: Existing runtime paths are sufficient for evidence gathering; this spec only records readiness.
- **Allowed deviation and why**: none.
- **Consistency impact**: The audit must use the exact readiness status vocabulary: `ready`, `ready with caveat`, `blocker`, `not applicable`.
- **Review focus**: Confirm that the audit stays repo-based and does not begin Decision Register feature design.
## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*
- **Touches OperationRun start/completion/link UX?**: no.
- **Shared OperationRun UX contract/layer reused**: N/A.
- **Delegated start/completion UX behaviors**: N/A.
- **Local surface-owned behavior that remains**: none.
- **Queued DB-notification policy**: N/A.
- **Terminal notification path**: N/A.
- **Exception required?**: none.
## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*
- **Shared provider/platform boundary touched?**: no.
- **Boundary classification**: N/A.
- **Seams affected**: none.
- **Neutral platform terms preserved or introduced**: N/A.
- **Provider-specific semantics retained and why**: none.
- **Why this does not deepen provider coupling accidentally**: The work is documentation-only and audits existing repo truth.
- **Follow-up path**: none.
## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|---|---|---|---|---|---|---|
| Feature readiness audit artifact | no | N/A | navigation, governance, evidence, reviews, RBAC, audit evidence only | none | no | `N/A - repository workflow only` |
## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
N/A - no operator-facing surface change.
## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*
N/A - no operator-facing surface change.
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
N/A - no operator-facing surface change.
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
N/A - no operator-facing surface change.
## Proportionality Review *(mandatory when structural complexity is introduced)*
- **New source of truth?**: no runtime source of truth. The audit artifact is a Spec Kit decision record for the next-spec gate.
- **New persisted entity/table/artifact?**: yes, documentation artifact only: `feature-readiness-audit.md`.
- **New abstraction?**: no.
- **New enum/state/reason family?**: no.
- **New cross-domain UI framework/taxonomy?**: no.
- **Current operator problem**: The productization queue needs a repo-backed readiness decision before the next feature spec starts.
- **Existing structure is insufficient because**: Roadmap and spec-candidate documents can drift from implemented repo truth; a gate artifact makes the current decision auditable.
- **Narrowest correct implementation**: One audit artifact plus normal Spec Kit prep files.
- **Ownership cost**: Reviewers must read the audit during the next-feature gate. No runtime maintenance cost.
- **Alternative intentionally rejected**: Starting the Decision Register spec immediately was rejected because repo evidence shows existing Decision Register implementation and tests that must be reconciled first.
- **Release truth**: Current-release preparation.
### Compatibility posture
This feature assumes a pre-production environment.
Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
Canonical replacement is preferred over preservation.
## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
- **Test purpose / classification**: Feature, Unit, and Browser-lane evidence review only. No new tests.
- **Validation lane(s)**: confidence and browser-existing evidence, using focused commands where practical.
- **Why this classification and these lanes are sufficient**: The change is documentation-only; existing focused tests are used to validate that the foundation surfaces remain green.
- **New or expanded test families**: none.
- **Fixture / helper cost impact**: none.
- **Heavy-family visibility / justification**: No heavy family is added. Existing browser smoke tests may be cited, but docs-only work does not require adding or changing browser tests.
- **Special surface test profile**: global-context-shell, standard-native-filament, shared-detail-family, monitoring-state-page evidence only.
- **Standard-native relief or required special coverage**: ordinary focused repo validation only.
- **Reviewer handoff**: Review `feature-readiness-audit.md`, confirm no application/test changes, and rerun the listed focused commands if needed.
- **Budget / baseline / trend impact**: none.
- **Escalation needed**: none.
- **Active feature PR close-out entry**: Guardrail.
- **Planned validation commands**:
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/NoLegacyTenantPanelRuntimeTest.php tests/Feature/Guards/NoActiveTenantResourceRoutesTest.php tests/Feature/Workspaces/WorkspaceIntendedUrlLegacyRejectionTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/PanelNavigationSegregationTest.php tests/Feature/Filament/AdminTenantSurfaceParityTest.php tests/Feature/Filament/AdminSharedSurfacePanelParityTest.php tests/Feature/Filament/TenantOwnedResourceScopeParityTest.php tests/Feature/Filament/InventoryCoverageAdminTenantParityTest.php tests/Feature/Filament/EntraGroupAdminScopeTest.php tests/Feature/Filament/EntraGroupGlobalSearchScopeTest.php tests/Feature/Filament/PolicyResourceAdminSearchParityTest.php tests/Feature/Filament/PolicyVersionAdminSearchParityTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/GovernanceDecisions/GovernanceDecisionRegisterBuilderTest.php tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php tests/Feature/Governance/DecisionRegisterPageTest.php tests/Feature/Governance/DecisionRegisterAuthorizationTest.php tests/Feature/Governance/GovernanceInboxPageTest.php tests/Feature/Governance/GovernanceInboxAuthorizationTest.php tests/Feature/Findings/FindingExceptionDecisionRegisterNavigationTest.php tests/Feature/Findings/FindingExceptionDetailDecisionSummaryTest.php tests/Feature/Findings/FindingExceptionDecisionRegisterBoundariesTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Evidence/EvidenceSnapshotResourceTest.php tests/Feature/Evidence/EvidenceSnapshotAuditLogTest.php tests/Feature/EnvironmentReview/EnvironmentReviewAuditLogTest.php tests/Feature/EnvironmentReview/EnvironmentReviewRegisterTest.php tests/Feature/EnvironmentReview/EnvironmentReviewRegisterRbacTest.php tests/Feature/Reviews/CustomerReviewWorkspacePageTest.php tests/Feature/Reviews/CustomerReviewWorkspaceAuthorizationTest.php tests/Feature/Reviews/CustomerReviewWorkspacePackAccessTest.php tests/Feature/Reviews/CustomerReviewWorkspaceLaunchLinksTest.php tests/Feature/Filament/GovernanceArtifacts/GovernanceArtifactDeepLinkContractTest.php`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php tests/Feature/Operations/LegacyRunRoutesNotFoundTest.php tests/Feature/ProviderConnections/LegacyRedirectTest.php tests/Feature/RequiredPermissions/RequiredPermissionsLegacyRouteTest.php tests/Feature/Guards/ManagedEnvironmentCanonicalRouteContractTest.php tests/Feature/Filament/PolicyVersionResolvedReferenceLinksTest.php`
- `git diff --check`
## User Scenarios & Testing *(mandatory)*
### User Story 1 - Readiness Matrix (Priority: P1)
As a productization reviewer, I need a repo-based readiness matrix after Specs 301-304 so I can decide whether the next feature spec can start.
**Why this priority**: The matrix is the core artifact that converts repo evidence into the requested GO / GO WITH CONDITIONS / NO-GO recommendation.
**Independent Test**: Review `feature-readiness-audit.md` and confirm every requested audit area appears with one of the required status values, repo evidence, caveat/blocker notes, and recommended actions.
**Acceptance Scenarios**:
1. **Given** Specs 301-304 are completed context, **When** the audit is read, **Then** each requested readiness area is classified as `ready`, `ready with caveat`, `blocker`, or `not applicable`.
2. **Given** a readiness area is blocked, **When** the audit is read, **Then** the blocker includes a recommended action.
---
### User Story 2 - Next Feature Gate Recommendation (Priority: P1)
As the next-spec owner, I need an explicit recommendation about Decision Register & Approval Workflow v1 so I do not start duplicate or unsafe productization work.
**Why this priority**: The user explicitly asked whether Decision Register & Approval Workflow v1 may be the next feature spec.
**Independent Test**: Review the Decision Register evaluation section and confirm it states whether the next feature may start and under which conditions.
**Acceptance Scenarios**:
1. **Given** repo evidence for existing Decision Register work is present, **When** the audit is completed, **Then** the recommendation distinguishes fresh duplicate feature work from a legitimate follow-up or close-out path.
2. **Given** roadmap/spec-candidate documents drift from repo truth, **When** the audit is completed, **Then** the drift is recorded as a condition rather than silently accepted as current truth.
---
### User Story 3 - Validation Evidence (Priority: P2)
As a reviewer, I need the audit to record focused validation commands and outcomes so the recommendation is grounded in current test evidence.
**Why this priority**: The audit is docs-only, but the readiness claim should still be backed by focused Filament/navigation, governance, findings, evidence, review, OperationRun, and route-retirement checks where practical.
**Independent Test**: Run or inspect the validation section and confirm `git diff --check` is included and no tests were added or changed.
**Acceptance Scenarios**:
1. **Given** focused validation commands can run locally, **When** the audit closes, **Then** their results are documented.
2. **Given** a validation command cannot run, **When** the audit closes, **Then** the reason and residual risk are documented.
### Edge Cases
- Existing product docs can describe a candidate as unimplemented while repo code and tests show implementation exists.
- Legacy routes can be absent from route lists while stale copy still references retired tenant-panel semantics.
- A docs-only gate can discover caveats that are not runtime blockers but should become conditions for the next feature spec.
- Focused tests can fail for pre-existing reasons; this audit must document the failure and avoid editing application code or tests.
## Requirements *(mandatory)*
### Functional Requirements
- **FR-001**: The spec MUST produce `specs/305-feature-readiness-gate-audit/feature-readiness-audit.md`.
- **FR-002**: The audit artifact MUST include a repo-based matrix covering all 12 requested readiness areas.
- **FR-003**: The matrix MUST use only the status values `ready`, `ready with caveat`, `blocker`, and `not applicable`.
- **FR-004**: Each blocker MUST include a recommended action.
- **FR-005**: The audit MUST explicitly evaluate whether Decision Register & Approval Workflow v1 may start as the next feature spec.
- **FR-006**: The audit MUST document a final recommendation of `GO`, `GO WITH CONDITIONS`, or `NO-GO`.
- **FR-007**: The work MUST NOT modify application runtime code, database migrations, tests, UI surfaces, or route behavior.
- **FR-008**: The work MUST NOT specify or implement the Decision Register feature.
- **FR-009**: The work MUST document focused validation commands and outcomes where practical, including `git diff --check`.
- **FR-010**: The audit MUST preserve Specs 301-304 as completed context and avoid reopening their implementation scopes.
### Key Entities *(include if feature involves data)*
- **Feature Readiness Audit**: A documentation-only artifact that records readiness status, repo evidence, caveats/blockers, recommended actions, validation outcomes, and the next-feature recommendation.
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-001**: `feature-readiness-audit.md` exists and includes all 12 requested readiness areas.
- **SC-002**: Every matrix row has a status from the required vocabulary, evidence, caveat/blocker note, and recommended action.
- **SC-003**: The audit states `GO`, `GO WITH CONDITIONS`, or `NO-GO` and explains the Decision Register next-feature decision.
- **SC-004**: `git diff --check` passes.
- **SC-005**: `git status --short` shows only `specs/305-feature-readiness-gate-audit/` changes.
## Assumptions
- Specs 301-304 are completed context and should not be edited by this feature.
- Existing code and tests are allowed as evidence, but this feature does not change them.
- If the repo already contains Decision Register implementation, the audit should treat that as repo truth even if roadmap or candidate docs are stale.
## Out of Scope
- Application code, migrations, factories, seeders, routes, policies, resources, pages, jobs, events, or services.
- Test creation, test edits, browser spec additions, or fixture changes.
- Decision Register & Approval Workflow v1 specification or implementation.
- Roadmap rewrite or broad product strategy changes.
- Reintroducing legacy tenant panel routes, compatibility aliases, or compatibility tests.

View File

@ -0,0 +1,60 @@
# Tasks: Feature Readiness Gate Audit
**Input**: Spec and plan from `/specs/305-feature-readiness-gate-audit/`
**Prerequisites**: Specs 301-304 are completed context and must remain read-only
## Format: `[ID] [P?] Description`
- **[P]**: Can run in parallel with other read-only inspection tasks
- Every task is docs-only unless explicitly listed as validation
## Phase 1: Setup
- [x] T001 Confirm current git branch and clean starting state before generating 305 artifacts.
- [x] T002 Read repo instructions, Constitution, Spec Kit templates, roadmap, and spec-candidate context.
- [x] T003 Create the 305 feature branch and initial Spec Kit plan/spec scaffold using repo scripts.
## Phase 2: Evidence Review
- [x] T004 [P] Review Specs 301-304 close-out notes and validation posture.
- [x] T005 [P] Review workspace/admin runtime provider registration and panel state.
- [x] T006 [P] Review environment-bound routes, tenant-owned resource traits, global search posture, and route retirement state.
- [x] T007 [P] Review OperationRun link and execution truth support.
- [x] T008 [P] Review governance inbox, Decision Register, findings/risk acceptance, evidence/stored report, review/review pack, RBAC, and audit/event foundations.
- [x] T009 [P] Identify relevant focused test lanes for Filament/navigation, governance, findings, evidence, reviews, OperationRun links, and legacy route retirement.
## Phase 3: Artifact Creation
- [x] T010 Replace the generated `spec.md` template with a docs-only readiness gate specification.
- [x] T011 Replace the generated `plan.md` template with a docs-only implementation plan.
- [x] T012 Create `tasks.md` for the docs-only audit workflow.
- [x] T013 Create `checklists/requirements.md` for the readiness artifact quality gate.
- [x] T014 Create `feature-readiness-audit.md` with the required repo-based matrix and GO / GO WITH CONDITIONS / NO-GO recommendation.
- [x] T015 Explicitly evaluate whether Decision Register & Approval Workflow v1 may start as the next feature spec.
## Phase 4: Validation
- [x] T016 Run focused legacy route/panel retirement tests from Specs 301-304 where practical.
- [x] T017 Run focused Filament/navigation/global-search tests from Specs 301-304 where practical.
- [x] T018 Run relevant Governance/Decision/Findings tests where practical.
- [x] T019 Run relevant Evidence/StoredReport/EnvironmentReview/ReviewPack tests where practical.
- [x] T020 Run relevant OperationRun link/legacy route tests where practical.
- [x] T021 Run `git diff --check`.
- [x] T022 Update `feature-readiness-audit.md` with validation outcomes.
## Phase 5: Close-Out
- [x] T023 Confirm `git status --short` is limited to `specs/305-feature-readiness-gate-audit/`.
- [x] T024 Confirm no application code, migrations, UI surfaces, or tests changed.
- [x] T025 Finalize the readiness recommendation and summarize residual conditions.
## Non-Goals Checklist
- [x] No runtime code changes.
- [x] No migrations.
- [x] No new UI surfaces.
- [x] No feature implementation.
- [x] No test edits.
- [x] No roadmap rewrite.
- [x] No Decision Register feature specification started.
- [x] No legacy compatibility reintroduced.