104 lines
4.2 KiB
Markdown
104 lines
4.2 KiB
Markdown
---
|
|
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. |