TenantAtlas/specs/413-focused-pilot-gate-recheck/spec.md

Feature Specification: Spec 413 - Focused Pilot Gate Recheck

Feature Branch: 413-focused-pilot-gate-recheck Created: 2026-06-24 Status: Draft / Ready for preparation review Type: Read-only focused browser/runtime gate / pilot-readiness verification Input: User-provided "Spec 413 - Focused Pilot Gate Recheck" draft from /Users/ahmeddarrazi/.codex/attachments/6fd4fa1e-54cf-4bf4-a1fc-1bc3327e3854/pasted-text.txt, specs/407-full-browser-ux-runtime-audit/, specs/412-pilot-readiness-remediation-pack/, docs/product/spec-candidates.md, docs/product/roadmap.md, and docs/product/standards/product-surface-contract.md.

Candidate Selection Context

• Selected candidate: Spec 413 - Focused Pilot Gate Recheck.
• Source location: Direct user-provided Spec 413 draft in the current request.
• Why selected: docs/product/spec-candidates.md reports no safe automatic next-best-prep target, but the operator supplied a concrete manual follow-through candidate. Spec 413 is the narrow read-only proof gate after Spec 412 and asks whether the Spec 407 pilot-readiness findings are actually closed before TenantPilot proceeds to controlled pilot preparation.
• Why close alternatives were deferred:
  • management-report-pdf-staging-runtime-validation remains a staging/Dokploy renderer validation lane, not this local focused recheck.
  • governance-artifact-lifecycle-retention-runtime is broader artifact lifecycle work and must not be hidden inside a pilot gate.
  • provider-readiness-onboarding-productization remains optional P2 roadmap work; this spec checks only the readonly provider no-access behavior that Spec 412 claims to have fixed.
  • A new full browser/UX/runtime audit is explicitly out of scope because Spec 407 already performed the broad audit and Spec 413 only rechecks the known remediation areas.
• Roadmap relationship: Supports the near-term path from post-audit remediation into controlled pilot preparation. The canonical phase sequence is Spec 407 full browser/runtime audit, Spec 412 pilot-readiness remediation, Spec 413 focused gate recheck, then a later Spec 414 controlled pilot preparation pack if this gate passes.
• Completed-spec guardrail result:
  • specs/407-full-browser-ux-runtime-audit/ exists as read-only audit context and must not be rewritten.
  • specs/412-pilot-readiness-remediation-pack/ contains completed tasks and an implementation report with focused tests/browser proof. It is completed implementation history and must not be normalized, unchecked, or stripped.
  • No specs/413-focused-pilot-gate-recheck/ package existed before this preparation. No existing local or remote branch matching 413-focused-pilot-gate-recheck was found before Spec Kit branch creation.
• Smallest viable implementation slice: Run a focused read-only recheck of the four Spec 407 findings remediated by Spec 412 and the adjacent regression boundaries: management PDF surfacing, report/PDF route authorization and state agreement, OperationRun index/detail load completion, finding hash demotion, readonly provider no-access clarity, and customer-safe/evidence/currentness/lifecycle/report regressions.
• Feature description for Spec Kit: Verify, through focused read-only browser/runtime evidence, that Spec 412 closed the known Spec 407 pilot-readiness findings without introducing authorization, customer-safe, report/PDF, OperationRun, evidence/currentness, lifecycle, or provider no-access regressions, and return a PASS, PASS WITH CONDITIONS, or FAIL decision before controlled pilot preparation.

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Spec 412 claims to remediate the Spec 407 pilot-readiness findings, but controlled pilot preparation should not proceed on implementation claims alone.
• Today's failure: Without a focused recheck, TenantPilot could move into pilot preparation while ready PDFs still surface incorrectly, report routes leak or block incorrectly, operations pages still fail browser readiness, finding detail still exposes technical hashes by default, or provider no-access behavior remains confusing or unsafe.
• User-visible improvement: The operator receives one evidence-backed gate answer for whether Spec 412 actually closed the known pilot-readiness blockers and whether Spec 414 controlled pilot preparation may start.
• Smallest enterprise-capable version: A read-only focused browser/runtime recheck over only the Spec 407/412 remediation areas, using existing actors, fixtures, routes, tests, logs, and browser inspection.
• Explicit non-goals: No fixes, no new or modified tests, migrations, refactors, seeders, factories, new surfaces, UI redesign, report-template changes, new OperationRun architecture, provider onboarding redesign, full browser audit, staging/Dokploy validation, legal hold or purge governance, commercial lifecycle work, support desk integration, docs outside this spec package, or application code changes.
• Permanent complexity imported: One Spec Kit package and a future audit/gate report. The severity labels, matrices, and PASS/PASS WITH CONDITIONS/FAIL result are report-only evidence, not runtime state, persisted truth, or a product status family.
• Why now: Spec 412 closed the bounded findings from Spec 407 and recorded focused proof. A follow-up gate should verify those claims before the project advances to controlled pilot preparation.
• Why not local: Unit or feature test results alone cannot prove browser navigation completion, visible PDF state agreement, customer-safe output, no-access clarity, and signed/unsigned report behavior together.
• Approval class: Core Enterprise.
• Red flags triggered: Browser-lane cost and audit matrix scope. Defense: this spec is read-only, focused on known findings, forbids runtime changes, and explicitly rejects a full browser audit.
• Score: Value: 2 | Urgency: 2 | Scope: 2 | Complexity restraint: 2 | Product proximity: 2 | Reuse: 2 | Total: 12/12
• Decision: approve as a bounded read-only focused gate recheck.

Problem Statement

Spec 413 answers:

Did Spec 412 actually close the known Spec 407 pilot-readiness blockers without introducing regressions?

The answer must be based on current browser/runtime proof and route/state/authorization evidence, not on the Spec 412 implementation report alone.

Product / Business Value

• Prevents false confidence after a remediation pack.
• Protects controlled pilot preparation from known report, operations, finding, and provider access risks.
• Keeps pilot gate work focused and avoids another whole-application audit.
• Produces a concrete decision: PASS, PASS WITH CONDITIONS, or FAIL.
• If the gate does not pass, it identifies one bounded remediation spec rather than a broad rewrite.

Primary Users / Operators

• Product owner deciding whether Spec 414 controlled pilot preparation can start.
• Workspace admins and system operators validating pilot-readiness flows.
• Customer reviewers whose report and customer-safe output boundaries must remain trustworthy.
• Readonly or limited actors whose provider no-access outcomes must remain safe and clear.
• Engineering reviewers who need a focused proof package before further implementation.

Spec Scope Fields (mandatory)

• Scope: focused read-only browser/runtime verification over existing surfaces.
• Primary Routes / Surfaces:
  • Review pack detail page and management PDF action area.
  • Stored report detail or report receipt page where available.
  • Management PDF download/open route.
  • Signed customer report route and unsigned/invalid-signature report route.
  • Admin OperationRun index and OperationRun detail.
  • OperationRun proof links from related surfaces.
  • Finding detail page.
  • Provider connection route and no-access behavior for readonly/limited actors.
  • Customer review/report path if connected to the PDF/report flow.
• Data Ownership: Existing ReviewPack, StoredReport, EnvironmentReview, OperationRun, Finding, ProviderConnection, workspace-owned, and managed-environment-owned records are read only. No table, field, state, ownership, or source-of-truth change is introduced.
• RBAC: Existing workspace membership, managed-environment entitlement, platform/admin/customer plane boundaries, signed URL authorization, member capability denials, and non-member deny-as-not-found behavior are verified only.
• Default filter behavior when environment context is active: Existing route-owned workspace/environment scope and explicit page filters remain repo truth. Any hidden context drift observed during recheck is recorded as a finding.
• Explicit entitlement checks preventing cross-tenant leakage: Representative direct route/download/report/provider/operation probes must be performed where existing actors and fixtures permit. Missing actor or fixture conditions are recorded as limitations, not proof.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production for this gate.

• Compatibility posture: read-only verification of current canonical behavior.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no new compatibility behavior is introduced.
• Why clean assessment is safe now: The recheck does not mutate runtime behavior. If defects are found, follow-up remediation should correct canonical behavior instead of adding compatibility shims.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• New table/form/state added
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

UI/Productization Coverage

N/A - no reachable UI surface impact.

• No-impact rationale: Spec 413 prepares a read-only verification gate. Future execution may navigate existing pages, inspect actions, open safe links, inspect browser console/logs, and download/open existing authorized reports, but it must not change pages, navigation, actions, views, routes, policies, resources, tests, assets, or runtime data.

Product Surface Impact

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: yes as the evaluation lens; no rendered product surface is changed by this spec.
• Page archetype: N/A for preparation. The recheck must classify inspected pages as Report, Receipt, Technical Annex, Decision, Settings, Search/Index, Dashboard, or System Admin where evidence supports it.
• Primary user question: "Is TenantPilot ready to move from post-audit remediation into controlled pilot preparation?"
• Primary action: Produce the focused gate decision and recommended next step.
• Surface budget result: N/A for preparation. The recheck flags default-view raw hashes, raw evidence links, OperationRun dominance, contradictory report state, or non-canonical status language as findings.
• Technical Annex / deep-link demotion: The recheck specifically verifies raw finding hashes and internal proof remain demoted from default customer/operator narrative.
• Canonical status vocabulary: The recheck verifies visible states use or map cleanly to Ready, Needs attention, Blocked, Running, Failed, Expired, Not configured, Unknown, Historical, Superseded, and allowed severity values.
• Visible complexity impact: neutral at runtime. The report may recommend bounded follow-up work, but must not perform it.
• Product Surface exceptions: none for preparation.

Browser Verification Plan (mandatory)

• Browser proof required?: yes for future Spec 413 execution because browser/runtime evidence is the product of this gate.
• No-browser rationale: N/A.
• Focused path when required:
  1. Review pack with ready stored management PDF shows ready/download/open state.
  2. Review pack with ready stored management PDF does not show "Generate management PDF" as the primary state.
  3. Stored report or report receipt state agrees with the review-pack UI.
  4. Authorized admin can download/open the management PDF.
  5. Unauthorized and cross-workspace actors cannot access/download the PDF/report.
  6. Signed report route renders only with a valid signature.
  7. Unsigned or invalid report route is blocked.
  8. Admin operations index completes browser navigation.
  9. Admin operations detail completes browser navigation.
  10. Finding detail default body no longer prominently exposes fingerprint or scope/source hashes.
  11. Readonly actor remains blocked from provider-connection route and sees a clearer no-access outcome.
  12. Focused regression probes cover customer-safe output, evidence/currentness, report lifecycle, OperationRun authorization, workspace/environment scoping, finding proof links, and provider authorization boundary.
• Primary interaction to execute: read-only navigation, safe link opening, report/PDF open or download where already authorized, direct unauthorized route probes, default detail inspection, console/log inspection, and confirmation-state inspection without executing destructive/high-impact actions.
• Console, Livewire, Filament, network, and 500-error checks: required.
• Full-suite failure triage: unrelated failures may be documented only when focused proof supports that classification.

Human Product Sanity Check (mandatory)

• Required?: yes as final gate sanity.
• No-human-sanity rationale: N/A.
• Reviewer questions: Does the gate answer whether Spec 412 closed the known issues? Are report/PDF, authorization, customer-safe, OperationRun, finding-detail, and provider no-access results concrete? Are remaining findings classified and tied to pilot impact? Is any recommended follow-up bounded?
• Planned result location: final Spec 413 audit report in the assistant response, or a spec-local report only if the operator explicitly requests a saved artifact during future execution.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed as read-only gate with no rendered surface change.
• Browser proof is required as the gate output.
• Human Product Sanity is planned as final-report sanity.
• Product Surface exceptions are none for preparation.
• Final report must state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and explicit no-implementation status.

Cross-Cutting / Shared Pattern Reuse

• Cross-cutting feature?: yes as a read-only gate over reports/downloads, OperationRun surfaces, finding detail, provider no-access, authorization boundaries, and customer-safe output.
• Interaction class(es): report/download action links, status/readiness messaging, evidence/report viewers, OperationRun proof links, authorization/no-access messaging, technical detail disclosure, signed routes, customer output.
• Systems touched: Spec artifacts only. Runtime systems are targets for read-only verification.
• Existing pattern(s) to extend: Product Surface Contract, Spec 407 audit structure, Spec 412 remediation matrices, Filament v5/Livewire v4 guidelines, RBAC/UiEnforcement conventions, OperationRun UX contract, signed report/download authorization patterns.
• Shared contract / presenter / builder / renderer to reuse: N/A - no runtime code.
• Allowed deviation and why: none.
• Consistency impact: The future report must use stable severity, gate, actor, route, expected/observed, evidence, residual severity, pilot impact, and follow-up language.
• Review focus: Confirm the gate stays read-only, focused, and does not become implementation or a full audit.

OperationRun UX Impact

• Touches OperationRun start/completion/link UX?: no runtime change. OperationRun index/detail load, proof links, and authorization are verified only.
• Shared OperationRun UX contract/layer reused: N/A.
• Delegated start/completion UX behaviors: N/A.
• Local surface-owned behavior that remains: N/A.
• Queued DB-notification policy: N/A.
• Terminal notification path: N/A.
• Exception required?: none.

Provider Boundary / Platform Core Check

• Shared provider/platform boundary touched?: no runtime seam change. Provider connection authorization and no-access copy are verified only.
• Boundary classification: provider connection remains provider-owned where provider-specific, while membership/capability denial and no-access behavior are platform-core.
• Seams affected: none by implementation; provider connection routes/pages/policies/middleware are audit targets.
• Neutral platform terms preserved or introduced: workspace, managed environment, provider connection, access, permission, membership, report, operation, evidence.
• Provider-specific semantics retained and why: existing Microsoft/provider labels remain only where existing provider connection behavior owns them.
• Why this does not deepen provider coupling accidentally: no code, UI labels, persistence, route, or vocabulary changes are introduced.
• Follow-up path: evidence-backed provider access regressions become one bounded remediation spec only if the gate fails.

UI / Surface Guardrail Impact

N/A - no operator-facing surface change. The gate inspects existing operator, customer, and system surfaces and records findings only.

Decision-First Surface Role

N/A - no surface changed. The gate verifies whether existing inspected pages still support a clear operator/customer decision after Spec 412.

Audience-Aware Disclosure

N/A - no disclosure changed. The gate verifies customer-safe, operator diagnostic, and internal technical detail boundaries.

UI/UX Surface Classification

N/A - no surface changed. Inspected surfaces may be classified in the final report when relevant.

Operator Surface Contract

N/A - no new or materially changed operator-facing page. The gate checks existing page purpose, dominant action, technical detail demotion, status clarity, and audience boundaries.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no runtime source of truth. The gate report is review evidence only.
• New persisted entity/table/artifact?: no application entity/table. A saved report artifact is allowed only under this spec directory if the operator explicitly requests it during execution.
• New abstraction?: no runtime abstraction.
• New enum/state/reason family?: no runtime status family. PASS/PASS WITH CONDITIONS/FAIL and P0-P3 severities are report-only.
• New cross-domain UI framework/taxonomy?: no runtime framework. Existing Product Surface and audit language is reused.
• Current operator problem: Controlled pilot preparation should not proceed until the known post-audit remediation claims have been rechecked.
• Existing structure is insufficient because: Spec 412 implementation proof is valuable but not the same as a fresh focused gate recheck across the actual pilot blockers and adjacent regression boundaries.
• Narrowest correct implementation: dirty-state capture, Spec 412 report inspection, route/surface probe, focused browser recheck, regression matrix, gate decision, and bounded follow-up recommendation.
• Ownership cost: one focused gate execution and one report. No recurring runtime maintenance.
• Alternative intentionally rejected: immediate Spec 414 preparation without recheck, another full browser audit, or remediating issues inside this gate.
• Release truth: current-release controlled pilot readiness gate.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Browser/read-only audit evidence plus optional existing Pest filters. No new test files are added or changed.
• Validation lane(s): Browser/read-only gate, safe route/log inspection, git diff --check, and selected existing tests only if appropriate for the local environment.
• Why this classification and these lanes are sufficient: The spec does not change runtime behavior; the value is current proof that visible state, route authorization, and browser readiness match the remediation contract.
• New or expanded test families: none.
• Fixture/helper/factory/seed/context cost: none added. Existing actors, fixtures, and runtime data only.
• Browser scope: focused paths listed in the Browser Verification Plan, not a full application audit.
• Deployment impact: none from preparation or future gate execution. The gate may record deployment/readiness conditions but does not change env vars, migrations, queues, scheduler, storage, assets, reverse proxy, or Dokploy config.

Functional Requirements (mandatory)

• FR-413-001: The gate MUST be read-only and MUST NOT modify application code, tests, migrations, seeders, factories, routes, policies, config, views, assets, database schema, runtime data intentionally, completed specs, or docs outside this spec package.
• FR-413-002: The gate MUST record branch, HEAD commit, dirty state, tracked changes, untracked files, git diff --check, active environment, base URL, and actors/fixtures used before and after recheck work.
• FR-413-003: The gate MUST inspect the Spec 412 implementation report and identify files changed, tests added/updated, browser proof claimed, remaining findings, deferred items, validation commands, and unrelated residual failures.
• FR-413-004: The gate MUST recheck management PDF surfacing with a ready stored management PDF where such a fixture exists.
• FR-413-005: A ready stored management PDF MUST show a ready/download/open state and MUST NOT show "Generate management PDF" as the primary state.
• FR-413-006: Stored report, report receipt, and review-pack UI states MUST agree for ready, missing, failed, unavailable, or inconsistent management PDF states.
• FR-413-007: Authorized management PDF download/open MUST work where a valid ready PDF fixture exists.
• FR-413-008: Unauthorized, cross-workspace, unsigned, invalid-signature, or otherwise unentitled report/PDF access MUST remain blocked and non-leaky.
• FR-413-009: Signed customer report routes MUST render only with valid signatures and customer-safe output.
• FR-413-010: OperationRun index and detail pages MUST complete usable browser navigation without current 500s or fatal Livewire/Filament errors under normal local audit conditions.
• FR-413-011: OperationRun proof links from related surfaces MUST remain usable and authorization-safe where fixtures permit.
• FR-413-012: Finding detail default body MUST NOT prominently expose fingerprint, scope hash, source fingerprint, detector/source keys, or equivalent raw technical identifiers.
• FR-413-013: Technical hashes, if still present, MUST be demoted to collapsed, support, operator, or technical detail and MUST NOT appear in customer-safe/default review context.
• FR-413-014: Readonly/limited provider-connection actors MUST remain blocked without redirect loops, login confusion for already-authenticated actors, or provider/workspace data leakage.
• FR-413-015: Authorized provider actors MUST still access intended provider connection surfaces where comparison is safe.
• FR-413-016: Focused regression checks MUST cover customer-safe report output, evidence/currentness labels, report lifecycle state display, OperationRun authorization, workspace/environment scoping, signed/unsigned report boundary, finding proof links, and provider authorization boundary.
• FR-413-017: Every P0/P1 finding MUST include route/page, actor, fixture/state, observed behavior, expected behavior, severity, why it matters, evidence, related Spec 407/412 finding, pilot impact, and recommended resolution.
• FR-413-018: The final report MUST include the Spec 407/412 Recheck Matrix, Report/PDF State Matrix, Focused Regression Matrix, Browser Proof table, Runtime/Console Results, Authorization/Customer-safe Boundary Results, Remaining Findings by severity, Readiness Decision table, commands run, and recommended next step.
• FR-413-019: The gate result MUST be exactly PASS, PASS WITH CONDITIONS, or FAIL.
• FR-413-020: If the gate does not pass, the recommendation MUST be one bounded remediation spec or explicit pilot exclusion. Do not recommend a broad audit by default.

Non-Functional Requirements

• NFR-413-001: No secrets, tokens, private signed URLs, raw credential payloads, sensitive customer data, stack traces, or raw provider payloads may be recorded in the final report.
• NFR-413-002: Browser conclusions must distinguish product defects from missing fixtures, unavailable actors, unavailable services, intentional 403/404 outcomes, and browser-tool timeout artifacts.
• NFR-413-003: The gate must avoid destructive/high-impact execution, data mutation, fixture creation, new report release, restore execution, provider connection mutation, or membership/workspace changes.
• NFR-413-004: The final report must state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, browser/test result, deployment impact, visible complexity outcome, and no-implementation status.
• NFR-413-005: Any existing test commands run during the gate must be reported accurately; do not claim test proof for commands not run.

User Scenarios And Independent Tests

User Story 1 - Product owner gets a gate decision (Priority: P1)

As the product owner, I need a focused PASS, PASS WITH CONDITIONS, or FAIL result so I can decide whether Spec 414 controlled pilot preparation may begin.

Independent Test: The final report includes Focused Pilot Gate Result, dirty state, actors/fixtures, matrices, browser proof, findings, readiness decision, commands run, and a recommended next action.

User Story 2 - Report and management PDF remediation is rechecked (Priority: P1)

As a workspace admin, I need existing ready management PDFs and report routes to present safe, coherent, authorized states before pilot preparation.

Independent Test: The Report/PDF State Matrix records ready, missing/failed/unavailable, authorized, unauthorized, cross-workspace, signed, and unsigned outcomes or explains unavailable fixtures.

User Story 3 - OperationRun navigation and finding/provider fixes are rechecked (Priority: P1)

As an operator, I need operations pages to be usable, finding detail to avoid default raw hashes, and provider no-access to be clear without weakening authorization.

Independent Test: Browser Proof records operations index/detail load, finding detail default content, readonly provider route behavior, and authorized comparison where safe.

User Story 4 - Focused regressions are caught without reopening a full audit (Priority: P2)

As the next implementation agent, I need any remaining issues grouped by pilot impact and bounded follow-up so remediation remains small.

Independent Test: Focused Regression Matrix classifies each included regression area with expected, observed, severity, and follow-up.

Required Final Report Structure

The final Spec 413 report MUST use this structure:

# Spec 413 Audit Report - Focused Pilot Gate Recheck

## A. Focused Pilot Gate Result
## B. Scope and Environment
## C. Dirty State
## D. Spec 407/412 Recheck Matrix
## E. Report/PDF State Matrix
## F. Focused Regression Matrix
## G. Browser Proof
## H. Runtime / Console Results
## I. Authorization / Customer-safe Boundary Results
## J. Remaining Findings
## K. Readiness Decision
## L. Validation / Audit Commands
## M. Recommended Next Step

Required Matrices

Spec 407/412 Recheck Matrix

Columns:

• Original Finding
• Spec 407 Severity
• Spec 412 Claimed Remediation
• Current Browser Proof
• Current Result
• Residual Severity
• Pilot Impact
• Follow-up

Required rows:

• Management PDF surfacing
• Operation route load timeout
• Finding hash demotion
• Readonly no-access clarity

Report/PDF State Matrix

Columns:

• Review Pack
• Stored Report
• PDF File State
• Lifecycle State
• Expected UI Action
• Observed UI Action
• Download/Open Result
• Authorization Result
• Status
• Risk

Focused Regression Matrix

Columns:

• Area
• Probe
• Expected
• Observed
• Regression?
• Severity
• Follow-up

Required rows:

• Customer-safe report output
• Signed report route
• Unsigned report route
• PDF download authorization
• Cross-workspace report boundary
• OperationRun authorization
• Finding evidence/proof link
• Provider readonly boundary

Gate Decision Rules

PASS

Use PASS only if:

• No P0 findings remain.
• No P1 findings remain.
• Spec 407 P1 management PDF surfacing issue is closed.
• Operations index/detail complete usable browser navigation.
• Finding hashes are no longer prominent in default body.
• Readonly provider no-access behavior is clearer and safe.
• Signed/unsigned report behavior remains correct.
• Report/PDF authorization remains safe.
• No customer-safe, evidence/currentness, lifecycle, or report regression is observed.
• TenantPilot can proceed to Spec 414 without local browser-audit exclusions for the remediated findings.

PASS WITH CONDITIONS

Use PASS WITH CONDITIONS only if:

• No P0 findings remain.
• Remaining findings are P2/P3, or an explicitly acceptable P1 has a clear pilot exclusion.
• Management PDF surfacing is fixed or safely product-decided.
• Authorization and customer-safe boundaries remain intact.
• Controlled pilot preparation may proceed with documented exclusions.

FAIL

Use FAIL if:

• Any P0 remains.
• Ready PDF still appears primarily as "Generate management PDF".
• Report/PDF authorization regresses.
• Signed/unsigned report boundary regresses.
• Operations pages still block normal operator navigation.
• Finding hashes remain prominently exposed in default/customer-facing body.
• Readonly no-access fix weakens authorization.
• Spec 412 introduced a broader regression requiring remediation before pilot preparation.

Severity Rules

• P0 - Blocker: serious safety or trust boundary failure, including unauthorized PDF/report download, cross-workspace report exposure, customer-safe report internal leakage, OperationRun unauthorized exposure, readonly provider access granted, or signed/unsigned report boundary failure.
• P1 - High: pilot preparation should not proceed without remediation or explicit exclusion, including ready PDF primary generate state, contradictory report states, operations navigation blocker, prominent default hashes, or signed report regression.
• P2 - Medium: productization issue that should be addressed before broader customer hardening, such as partial hash demotion, slow but usable operations route, or clearer-but-imperfect no-access copy.
• P3 - Low: minor copy or layout polish only.

Acceptance Criteria

• AC-413-001: The gate execution is read-only.
• AC-413-002: Dirty state before and after is recorded.
• AC-413-003: Spec 412 implementation report is inspected.
• AC-413-004: All four Spec 407/412 remediation areas are browser-rechecked or explicitly marked unavailable with reason.
• AC-413-005: Management PDF surfacing is tested with a ready stored report/PDF where fixture exists.
• AC-413-006: PDF download/open authorization is tested.
• AC-413-007: Signed and unsigned report routes are tested.
• AC-413-008: OperationRun index and detail load behavior are tested.
• AC-413-009: Finding detail hash demotion is tested.
• AC-413-010: Readonly provider no-access behavior is tested.
• AC-413-011: Focused regression checks are performed for customer-safe, report, evidence/currentness, authorization, lifecycle, and provider boundaries.
• AC-413-012: Final report includes the required matrices and gate decision.
• AC-413-013: Final report clearly says whether Spec 414 may proceed.

Success Criteria

• SC-413-001: The operator can decide whether TenantPilot is ready for Spec 414 controlled pilot preparation.
• SC-413-002: No known Spec 407/412 pilot-readiness finding is left unverified without an explicit limitation.
• SC-413-003: Any residual risk is classified by severity, pilot impact, and bounded follow-up.
• SC-413-004: No application implementation or runtime mutation is performed by the gate.

Edge Cases

• Required actor or fixture is unavailable.
• Ready management PDF fixture is unavailable.
• Browser tool times out while the page appears usable; document the distinction carefully.
• A direct route returns intentional 403/404 for isolation.
• Signed route cannot be tested without exposing a private signed URL; record sanitized proof only.
• Existing broad tests have unrelated failures; classify only with focused evidence.

Out Of Scope

• Full browser/UX/runtime audit.
• Application fixes.
• New or modified tests.
• Migrations, seeders, factories, or fixtures.
• UI redesign.
• New report templates or PDF architecture.
• New OperationRun architecture.
• New finding taxonomy.
• Provider onboarding redesign.
• Legal hold, purge, or export-before-delete governance.
• Staging/Dokploy deployment validation.
• Commercial lifecycle work.
• Support desk integration.
• Reopening or rewriting Specs 407 or 412.

Assumptions

• The gate runs against local/dev unless the operator explicitly approves another environment.
• Existing actors and fixtures are used; unavailable actors or fixtures are limitations.
• Spec 412 implementation report is accepted as claimed-remediation context, not as proof.
• Report output is response-only unless the operator explicitly requests a saved spec-local report artifact.

Risks

• Existing local data may not include a ready management PDF or required actor combinations.
• Browser auth/session setup may block customer reviewer, readonly, unauthorized, or cross-workspace proof.
• Streamed download bodies may require feature-route proof rather than browser-body assertions.
• Broad historical residual failures may confuse gate results; this spec requires focused classification.

Open Questions

• None blocking preparation. During gate execution, record missing actors, fixtures, services, or routes as limitations instead of inventing proof.

Follow-up Spec Candidates

Follow-up specs must be created only after the Spec 413 report identifies evidence-backed findings:

• Bounded report/PDF surfacing remediation if ready PDF/report state remains P1.
• Bounded OperationRun browser-load remediation if operations navigation remains P1.
• Bounded authorization/customer-safe boundary remediation if report, customer output, provider, or operation access regresses.
• Spec 414 Controlled Pilot Preparation Pack if this gate passes or passes with acceptable documented conditions.

Candidate Selection Gate Result

PASS. The selected candidate was directly supplied by the operator, is not already covered by an existing active or completed Spec 413 package, preserves completed Spec 407/412 history, aligns with the roadmap path toward controlled pilot preparation, and is scoped as a small read-only verification gate.

Spec Readiness Gate Result

PASS FOR IMPLEMENTATION PREPARATION once plan.md, tasks.md, and checklists/requirements.md in this package are reviewed together. No product question blocks a later read-only gate execution.