Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification

Implement one complete, approved tenant-isolated user journey through the existing application stack. Build only the vertical slice defined in the supplied specification. Do not expand the work into an entire SaaS product, a generic tenancy framework, or an architecture document.

## Required inputs

Approved vertical-slice specification:
{{approved_vertical_slice_specification}}

Repository and stack context:
{{repository_and_stack_context}}

Tenancy, identity, and authorization model:
{{tenancy_identity_and_authorization_model}}

Data interfaces and test fixtures:
{{data_interfaces_and_test_fixtures}}

Acceptance criteria and authorized scope:
{{acceptance_criteria_and_authorized_scope}}

## Evidence and assumption rules

1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite file paths, symbols, schema objects, routes, policy rules, commands, and test output where available.
2. Do not invent tenant-resolution rules, roles, permissions, ownership rules, database fields, lifecycle states, APIs, job behavior, cache behavior, storage conventions, search capabilities, test results, credentials, or approvals.
3. Treat the supplied tenancy and authorization model as the authority contract. If it conflicts with repository behavior or omits a rule that affects isolation, stop the affected implementation path and request a decision from the product owner and security reviewer.
4. UI visibility is not authorization evidence. Require server-side enforcement at every applicable entry point and data boundary.
5. Use synthetic tenants, identities, records, files, and search documents. Do not request secrets, production tenant access, or real customer data.
6. Preserve unrelated repository changes and existing tenant behavior. Do not reformat, replace, or repair work outside the approved slice.
7. Separate changes actually applied and tests actually run from proposed changes, expected behavior, and unverified assumptions.

## Authorization boundaries

- Implementation requires an authorized repository, a bounded journey specification, an explicit tenancy and identity model, safe fixtures, and permission to change the identified files.
- Inspect only the supplied workspace, configuration, schemas, interfaces, fixtures, and command output. Do not imply access to identity providers, production tenants, external storage, search services, queues, or deployment systems unless the session provides direct evidence.
- Change only the approved files, schemas, configuration, and test surfaces. Use local fakes, isolated services, or approved non-production endpoints for jobs, notifications, storage, search, and other integrations.
- Do not broaden roles or permissions, replace the identity provider, access production tenant data, activate live billing, deploy, merge, push, publish, communicate externally, or run destructive migrations.
- Obtain separate approval before any schema migration with data-loss or lock risk, dependency installation, identity-model change, new cross-system permission, destructive action, or production-adjacent operation.
- Stop with a blocked handoff when the approved specification, tenant boundary, safe environment, essential fixture, or authority is absent.

## Implementation method

### 1. Establish the vertical-slice contract

Restate the single triggering actor, tenant context, entry route or interface, authorized action, domain transition, persisted or returned result, and observable completion condition. List explicit non-goals.

Identify every actor and role in the journey, how the active tenant is resolved, which tenant owns each record, and what happens when the tenant is missing, disabled, deleted, mismatched, or changed. Do not add states or permissions that the specification does not authorize.

### 2. Inspect the repository and current tenant boundary

Before editing, inspect the working-tree state, framework and runtime, route and middleware registration, authentication integration, tenant resolver, policies or permission checks, request validation, domain services, models, schema and migrations, query scopes, API resources, jobs, events, notifications, caches, file or object storage, search or indexes, exports, tests, feature flags, and observability.

Trace the current journey end to end. Record each source as inspected, unavailable, or not relevant. Identify repository conventions and pre-existing isolation risks without broadening the repair scope.

### 3. Set a concise implementation checkpoint

Map every acceptance criterion to affected files, symbols, data objects, authorization rules, test cases, commands, external-effect fakes, and rollback actions. State the smallest coherent change set and the approved schema effect, if any.

If implementation would require inventing the tenancy model, replacing foundational identity behavior, changing unrelated modules, accessing production, or using unavailable systems, stop. Provide a precise blocked handoff instead of a fictional implementation.

### 4. Implement trusted tenant resolution

Resolve the active tenant from the approved trusted identity, membership, route-binding, or server-side context. Do not trust a client-supplied tenant identifier by itself. Validate membership status, tenant status, and permitted role before entering domain logic.

Ensure modified URLs, query parameters, request bodies, headers, object identifiers, and API payloads cannot select another tenant or elevate a role. Return the approved denied or not-found behavior without leaking whether another tenant’s object exists.

### 5. Implement validation, authorization, and domain behavior

Apply server-side request validation and explicit authorization before reads, writes, exports, jobs, notifications, or other effects. Keep policy, service, and persistence rules aligned with the approved ownership and role model.

Implement the specified domain transition and its loading, empty, denied, validation, conflict, error, and recovery states. Keep the change bounded to the approved journey. Do not add generic administration, billing, onboarding, or unrelated tenant features.

### 6. Implement tenant-scoped persistence

Use the approved tenant key, ownership relationship, unique constraints, indexes, and transaction boundaries. Make query scoping explicit at trust-sensitive points. Validate that create, find, update, delete, aggregate, and export operations cannot cross the tenant boundary.

For approved schema changes, inspect existing data and migration conventions first. Use reversible migrations and explain lock, backfill, nullability, uniqueness, and rollback behavior. Do not run destructive or production migrations without separate approval.

Prevent global uniqueness assumptions from incorrectly blocking legitimate values across tenants or allowing duplicates where uniqueness is tenant-scoped. Do not treat a default model scope as the only protection for sensitive direct-object access.

### 7. Carry isolation across asynchronous and derived systems

Where the slice uses background jobs, events, notifications, cache entries, files, object storage, search indexes, or exports:

- include the approved tenant identity in the durable payload or storage namespace;
- re-resolve and validate tenant and actor authority at execution time where required;
- namespace cache keys and invalidation by tenant;
- isolate storage paths, retrieval policies, and generated URLs;
- apply tenant filters to search indexing and retrieval;
- ensure exports contain only the current authorized tenant’s rows;
- send notifications only to test sinks during verification;
- prevent stale jobs or cached data from surviving a disabled or deleted tenant contrary to the specification.

Do not claim these surfaces are isolated if they were unavailable or untested.

### 8. Implement interfaces and recovery states

Implement the approved web, API, or command interface using repository conventions. Preserve accessibility, keyboard behavior, responsive states, API contracts, pagination, error shapes, and rate controls where applicable.

Provide explicit behavior for loading, no eligible records, validation denial, authorization denial, missing tenant, disabled tenant, stale state, duplicate submission, partial failure, retriable failure, and rollback or feature disablement.

### 9. Add audit and observability evidence

Record the minimum safe tenant, actor, action, object, correlation, result, and failure metadata required by the supplied contract. Do not log secrets, sensitive payloads, or unnecessary personal data. Make authorization denial, cross-tenant attempts, job failures, export generation, and feature disablement observable where required.

Audit evidence records what the application attempted or decided. It does not itself prove isolation or authorize access.

### 10. Run the tenant-isolation test suite

Use at least two synthetic tenants and multiple roles, including an allowed and a denied role. Test the complete journey and all applicable supporting surfaces:

- authorized access inside the active tenant;
- unauthorized and inactive roles;
- another tenant’s valid object identifier;
- direct-object access and modified URLs, query parameters, request payloads, and headers;
- tenant-scoped create, read, update, aggregation, and delete behavior where included;
- duplicate submissions and validation failures;
- jobs executed with the expected tenant and attempts to substitute another tenant;
- cache-key isolation, stale cache, and invalidation;
- file paths, object retrieval, signed URLs, and storage namespace isolation;
- search indexing and result filtering;
- export row isolation and direct export retrieval;
- partial failure and retry behavior;
- missing, disabled, or deleted tenant behavior where specified;
- feature flag off and rollback behavior.

Record the exact fixture identities, commands, exit states, and relevant assertions without exposing secrets. Sequential happy-path tests are insufficient. A passing UI test does not prove server-side authorization, and one data-layer test does not prove jobs, caches, files, search, or exports.

### 11. Reconcile acceptance and prepare rollback

Map every acceptance criterion to code and execution evidence. Mark it demonstrated, partially demonstrated, failed, blocked, or not run. Preserve failures and pre-existing issues rather than weakening assertions.

Define feature-flag behavior or the smallest reversible control, schema rollback constraints, job and cache cleanup, search or file recovery, and restoration steps. Release remains a decision for the security reviewer and release owner.

## Stop conditions

Stop with a precise blocked handoff when:

- tenant resolution, ownership, role, or disabled-state rules are missing or conflicting;
- the authorized repository or safe test environment is unavailable;
- implementation would require production tenant access, live billing, an identity-provider replacement, or broader permission changes;
- the slice cannot be tested with two synthetic tenants and multiple roles;
- a required job, cache, storage, search, or export boundary cannot be inspected or safely faked;
- a destructive migration or irreversible operation lacks separate approval and recovery evidence;
- cross-tenant or direct-object tests fail and cannot be corrected within scope;
- rollback cannot preserve tenant data integrity.

## Output contract

Return these sections:

1. **Vertical-slice implementation status**: `Implemented and tested in the authorized environment`, `Partially implemented`, or `Blocked`. Separate inspected, applied, executed, demonstrated, and unverified work.
2. **Evidence and assumptions register**: source, classification, location, relevance, conflict or limitation, and required owner.
3. **Tenant-boundary map**: entry point, trusted tenant source, actor and role, object ownership, authorization control, persistence scope, derived-system scope, denied behavior, and evidence.
4. **Specification-to-code traceability**: requirement or acceptance criterion, file and symbol, implementation, test, result, and unresolved gap.
5. **Repository change manifest**: file, schema, configuration, job, cache, storage, search, or test item changed; purpose; state; and rollback action.
6. **Schema and persistence record**: tenant keys, ownership links, constraints, indexes, query boundaries, transaction behavior, migration status, and rollback limits.
7. **Authorization matrix**: tenant state, actor role, action, resource ownership, expected result, enforcement location, test result, and evidence.
8. **Cross-tenant isolation test ledger**: test tenant and actor, target tenant and object, interface, attempted manipulation, expected denial, observed result, status, and evidence.
9. **Failure and recovery matrix**: failure, affected state, containment, retry rule, recovery, cleanup, owner, and test evidence.
10. **Feature-flag or rollback plan**: disablement, schema considerations, job and cache cleanup, storage/search recovery, data reconciliation, and verification.
11. **Security and release-owner handoff**: remaining risks, untested surfaces, schema approval, access review, release prerequisites, and accountable owners.
12. **Completion statement**: reconcile every acceptance criterion and end with the smallest safe next action.

Completion requires actual authorized code or configuration changes for the bounded journey, server-side tenant enforcement, matching immutable versioned evidence where applicable, executed cross-tenant tests using at least two synthetic tenants and multiple roles, coverage of every included derived-system boundary, and a viable rollback or feature-disablement path. Do not claim the whole SaaS product was built or that tenant isolation, security, or production readiness is established beyond the recorded evidence.