TenantAtlas/.codex/prompts/tenantpilot.spec-candidates.md

description
Turn TenantPilot architecture audit findings into bounded spec candidates without colliding with active spec numbering.

You are a Senior Staff Engineer and Enterprise SaaS Architect working on TenantPilot / TenantAtlas.

Your task is to produce spec candidates, not implementation code.

Before writing anything, read and use these repository files as binding context:

• docs/audits/tenantpilot-architecture-audit-constitution.md
• docs/audits/2026-03-15-audit-spec-candidates.md
• specs/110-ops-ux-enforcement/spec.md
• specs/111-findings-workflow-sla/spec.md
• specs/134-audit-log-foundation/spec.md
• specs/138-managed-tenant-onboarding-draft-identity/spec.md

Goal

Turn the existing audit-derived problem clusters into exactly four proposed follow-up spec candidates.

The four candidate themes are:

1. queued execution reauthorization and scope continuity
2. tenant-owned query canon and wrong-tenant guards
3. findings workflow enforcement and audit backstop
4. Livewire context locking and trusted-state reduction

Numbering rule

• Do not invent or reserve fixed spec numbers unless the current repository state proves they are available.
• If numbering is uncertain, use Candidate A, Candidate B, Candidate C, and Candidate D.
• Only recommend a numbering strategy; do not force numbering in the output when collisions are possible.

Output requirements

Create exactly four spec candidates, one per problem class.

For each candidate provide:

1. Candidate label or confirmed spec number
2. Working title
3. Status: Proposed
4. Summary
5. Why this is needed now
6. Boundary to existing specs
7. Problem statement
8. Goals
9. Non-goals
10. Scope
11. Target model
12. Key requirements
13. Risks if not implemented
14. Dependencies and sequencing notes
15. Delivery recommendation: hotfix, dedicated spec, or phased spec
16. Suggested implementation priority: Critical, High, or Medium
17. Suggested slug

At the end provide:

A. Recommended implementation order B. Which candidates can run in parallel C. Which candidate should start first and why D. A numbering strategy recommendation if active spec numbers are not yet known

Writing rules

• Write in English.
• Use formal enterprise spec language.
• Be concrete and opinionated.
• Focus on structural integrity, not patch-level fixes.
• Treat the audit constitution as binding.
• Explicitly say when UI-only authorization is insufficient.
• Explicitly say when Livewire public state must be treated as untrusted input.
• Explicitly say when negative-path regression tests are required.
• Explicitly say when OperationRun or audit semantics must be extended or hardened.
• Do not duplicate adjacent specs; state the boundary clearly.
• Do not collapse all four themes into one umbrella spec.

Candidate-specific direction

Candidate A — queued execution reauthorization and scope continuity

• Treat this as an execution trust problem, not a simple authorize() omission.
• Cover dispatch-time actor and context capture, handle-time scope revalidation, capability reauthorization, execution denial semantics, and audit visibility.
• Define what happens when authorization or tenant operability changes between dispatch and execution.

Candidate B — tenant-owned query canon and wrong-tenant guards

• Treat this as canonical data-access hardening.
• Cover tenant-owned and workspace-owned query rules, route model binding safety, canonical query paths, anti-pattern elimination, and required wrong-tenant regression tests.
• Focus on ownership enforcement, not generic repository-pattern advice.

Candidate C — findings workflow enforcement and audit backstop

• Treat this as a workflow-truth problem.
• Cover formal lifecycle enforcement, invalid transition prevention, reopen and recurrence semantics, and audit backstop requirements.
• Make clear how this extends but does not duplicate Spec 111.

Candidate D — Livewire context locking and trusted-state reduction

• Treat this as a UI/server trust-boundary hardening problem.
• Cover locked identifiers, untrusted public state, server-side reconstruction of workflow truth, sensitive-state reduction, and misuse regression tests.
• Make clear how this complements but does not duplicate Spec 138.