# Software requirements specification

> SYNTHETIC REFERENCE • SAMPLE-PENTASCOPE-MASTER • v1.0.0 • 2026-09-08 • Draft • all 96 cases Not Run. This is a proposed learning and acceptance pack, not customer source truth, test evidence or release approval. No project is created or seeded by opening it.

## Purpose and system context

Artifact SRS-MASTER-001; upstream BRD-MASTER-001; version 1.0.0; author role Business Analyst; approvers unset. This proposed specification makes the master quality journey testable. Local files establish discovered surfaces only; all authored acceptance obligations remain recommendations until a project owner adopts and approves them.

Browser → frontend same-origin `/api/*` proxy → backend business/authentication layer → MySQL records and private S3-compatible files. The backend owns AI routes, workers, outbound webhooks, evidence URLs and credential encryption. The backend also exposes the versioned `/api/v1/*` alias. Use the deployed API contract and observed request shape when adapting tests; this document deliberately does not invent request payload schemas.

## Actor and permission baseline

The runtime membership roles in `pentascope-be/lib/account-auth.ts` are **owner, editor, tester, viewer**. Reviewer means a workflow responsibility. Requirements manager is capability-based (`requirements:manage`) and must be assigned by the permitted owner flow. Always recheck route-specific authorization and the current membership version.

- owner: wildcard project capabilities and member/key/project governance.
- editor: project read, requirements edit, tests edit, review decisions, defects edit, evidence read and usage read in the default capability map. Requirements approval may additionally require requirements:manage; do not infer it from the editor title.
- tester: project read, tests edit, execution manage, defects edit and evidence read in the default capability map.
- viewer: project read and evidence read; no write authority.
- widget:write: restricted GET project metadata and POST issue/issue attachment surfaces under the central service policy; not a general read or execution identity.
- agent:execute: governed command execution/credential lease/result surfaces; no member/owner administration.
- srs:edit: separately restricted SRS service capability when deliberately issued; never a person's shared account.

## Domain data dictionary

- Account: server ID, normalized email, display name, password hash, verification/MFA state and locale. Email identifies a named person; passwords/MFA secrets are never documentation data.
- Session: server ID, account reference, creation/expiry/revocation state; browser session cookie is protected and project selector is non-authoritative.
- Project: server ID, name, environment, approved base URL and status. All child records have project ownership; new projects have no implied business sources.
- Membership: account/project IDs, owner/editor/tester/viewer role, capabilities, active/removed status and membership version. Ownership transfer is atomic.
- Source document: document ID, type, filename, byte size, content hash, private object reference and version. Retain source locators without leaking storage secrets.
- Analysis job: project/source/hash, registered operation, attempt/lease/progress/terminal state and sanitized error. Queued or generated work is not evidence.
- Requirement/story: stable external identity, module/workflow, source references, business rule, detailed criteria IDs, scope/review state and immutable revisions.
- Finding/decision: requirement or artifact version reference, severity/blocking stage, rationale, actor and time. An unresolved blocker prevents its gate.
- Test case/suite: stable case ID/version, source requirement/criterion links, type/risk/role/data, steps, expected outcomes, approval and readiness. Design state is separate from execution.
- Execution preview/command: selected current cases, membership version, target/options, hash, claim/progress state and service actor. A preview is neither a run nor approval of an unreviewed target.
- Credential: project ID, role/login metadata, encrypted secret and availability status. Store and use only a reference in ordinary case/plan context.
- Run/assertion/step: exact case/build/command IDs, actual observations, timestamps, computed outcome and evidence references. Missing actuals can never support a pass.
- Evidence asset: project/object metadata, content/type and authorized signed access. Source objects remain private; expiry/retention is an approved policy decision.
- Defect/fix/retest: reproduction, expected/actual, source case/run, triage decision, delivery/build, verified retest run and closure history.
- Schedule/webhook delivery: validated selection or event, owner/scope, due time/attempts/status and actual transport receipts. Scheduled/queued does not mean executed/delivered.
- AI usage/media: operation/policy/provider/model/tokens/cost/latency metadata and private validated image references. No source/prompt/response body is stored in usage receipts.

IDs are strings generated or accepted by the current server contract. All foreign references must belong to the authenticated project. Timestamps in evidence are ISO-8601 UTC with the displayed UI timezone recorded separately. Retention/deletion and formal quantitative NFRs remain GAP-003 through GAP-006.

## End-to-end states and exceptions

The authoring journey is Draft → In Review → an explicit permitted decision (Approved, Changes Requested or Rejected). Reopening/editing creates an attributable current version and invalidates stale dependent work. Source jobs report their actual queued/running/retry/terminal state. Test designs must be approved and browser-ready before the governed preview/command flow can queue them. Manual-only cases remain manual.

Execution records actual step and assertion receipts. A case can only pass when all required checks are satisfied with adequate evidence. Failed assertions fail it; missing setup or a missing oracle blocks it. Defect flow is Open → an authorized triage decision → fix delivery with build → Awaiting Retest → matching evidence-backed closure, subject to current transition policy. Invalid transitions return actionable errors without partial mutation. Historical versions/results remain separate from current readiness.

For timeout/provider failure, keep the source identity, show the observed error and retry only within policy. For missing/mismatched source or target, return a gap rather than a fabricated artifact. For denied access, return no unauthorized data. For stale versions, require reload/review. For notification failures, preserve the business event and actual failed/retry delivery state; never infer receipt by the recipient.

## Detailed requirements and stories

### REQ-001 — Named account registration and recovery

**US-001**: As account holder, I need named account registration and recovery so that I can access my own work through a verified identity and recover access without giving an attacker control. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** People use their own verified account; invalid registration and recovery input never grants project access.

**Source and lineage:** SRC-001 (`pentascope-be/lib/account-auth.ts`); BR-001 → OBL-001 → REQ-001 → US-001. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/en/login`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** email: normalized lowercase, valid format, maximum 320 characters; password: 12–1024 characters; verification/recovery token: secret, single-use, expiry from deployed policy.

**Preconditions and trigger:** A unique sample mailbox is controlled by the tester and email delivery uses a test sink. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Register the mailbox with a 12-character test password, open the delivered verification link, then sign in.

**Successful postcondition:** Verification identifies the intended account and sign-in reaches the project selection flow; no unrelated project becomes visible.

**Alternative / failure flows:** Try an 11-character password, then a malformed email, then a valid 12-character password and email using separate attempts. Expected: Invalid attempts show actionable validation and create no usable account; the valid boundary can enter verification. Request recovery, redeem the link once with a new compliant password, then open the same link again. Expected: The used link cannot reset the password a second time; the first reset remains effective.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-001-01** — Given A unique sample mailbox is controlled by the tester and email delivery uses a test sink. When Register the mailbox with a 12-character test password, open the delivered verification link, then sign in. Then Verification identifies the intended account and sign-in reaches the project selection flow; no unrelated project becomes visible. Verification: TC-001.

- **AC-001-02** — Given No account exists for the test mailbox. When Try an 11-character password, then a malformed email, then a valid 12-character password and email using separate attempts. Then Invalid attempts show actionable validation and create no usable account; the valid boundary can enter verification. Verification: TC-002.

- **AC-001-03** — Given A verified sample account and its test inbox exist. When Request recovery, redeem the link once with a new compliant password, then open the same link again. Then The used link cannot reset the password a second time; the first reset remains effective. Verification: TC-003.

### REQ-002 — Session revocation and MFA

**US-002**: As account holder, I need session revocation and mfa so that I can terminate unwanted sessions and protect sign-in with a second factor. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Account sessions and MFA operations validate current identity and expose no reusable secret after setup.

**Source and lineage:** SRC-002 (`pentascope-be/app/api/account-mfa/route.ts`); BR-002 → OBL-002 → REQ-002 → US-002. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/en/account`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** sessionId: server-issued; MFA code: time-based numeric code; recovery code: secret and single-use; locale: supported UI choice.

**Preconditions and trigger:** Two isolated browser profiles are signed in to the same sample account. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** In profile A revoke profile B from account sessions; in B request protected account and project data.

**Successful postcondition:** Profile B loses authorized access while A remains usable.

**Alternative / failure flows:** Sign out, sign in with the password, submit an incorrect MFA code, then a current correct code. Expected: The incorrect code cannot complete sign-in; the current correct code can. Use the recovery code to finish sign-in, sign out, then attempt to reuse it. Expected: First use can recover access; second use is rejected.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-003.

**Acceptance criteria:**

- **AC-002-01** — Given Two isolated browser profiles are signed in to the same sample account. When In profile A revoke profile B from account sessions; in B request protected account and project data. Then Profile B loses authorized access while A remains usable. Verification: TC-004.

- **AC-002-02** — Given MFA enrollment was completed with a tester-controlled authenticator. When Sign out, sign in with the password, submit an incorrect MFA code, then a current correct code. Then The incorrect code cannot complete sign-in; the current correct code can. Verification: TC-005.

- **AC-002-03** — Given The sample account has MFA and an unused recovery code held outside the pack. When Use the recovery code to finish sign-in, sign out, then attempt to reuse it. Then First use can recover access; second use is rejected. Verification: TC-006.

### REQ-003 — Project creation and strict data isolation

**US-003**: As owner, I need project creation and strict data isolation so that my team can start with its own sources and keep other projects confidential. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** A new project begins empty and every project read/write uses the authenticated selected project.

**Source and lineage:** SRC-003 (`pentascope-be/app/api/account-projects/route.ts`); BR-003 → OBL-003 → REQ-003 → US-003. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/en/projects`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** projectId: server-issued and immutable; name: required; base URL/environment: configured target metadata; browser selector: not authorization.

**Preconditions and trigger:** The named owner is signed in and has no project called SAMPLE-A-{runKey}. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Create SAMPLE-A-{runKey}, select it, then open its SRS, test library and issues.

**Successful postcondition:** The project exists and each unpopulated area gives an honest empty state; no bundled business graph or cases are attached.

**Alternative / failure flows:** As A substitute B project and artifact IDs into observed read and write requests. Expected: The server denies access without returning B content and without modifying B. Open A source details, switch to B, navigate back and refresh the details route. Expected: Every displayed source and count belongs to the current authorized project or an explicit unavailable state.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-001.

**Acceptance criteria:**

- **AC-003-01** — Given The named owner is signed in and has no project called SAMPLE-A-{runKey}. When Create SAMPLE-A-{runKey}, select it, then open its SRS, test library and issues. Then The project exists and each unpopulated area gives an honest empty state; no bundled business graph or cases are attached. Verification: TC-007.

- **AC-003-02** — Given Owner A belongs only to SAMPLE-A; owner B belongs only to SAMPLE-B containing a marker B-PRIVATE-{runKey}. When As A substitute B project and artifact IDs into observed read and write requests. Then The server denies access without returning B content and without modifying B. Verification: TC-008.

- **AC-003-03** — Given One account belongs to A and B, each with a different source-title marker. When Open A source details, switch to B, navigate back and refresh the details route. Then Every displayed source and count belongs to the current authorized project or an explicit unavailable state. Verification: TC-009.

### REQ-004 — Membership and invitation governance

**US-004**: As owner, I need membership and invitation governance so that collaborators receive only the access they need and ownership is never lost. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Only authorized owners manage named memberships; invitations and revocation preserve project ownership and least privilege.

**Source and lineage:** SRC-004 (`pentascope-be/app/api/project-members/route.ts`); BR-004 → OBL-004 → REQ-004 → US-004. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/en/members`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** role: owner/editor/tester/viewer; capabilities: server-maintained; invitation email: controlled test inbox; membership version: increases on change.

**Preconditions and trigger:** Owner A controls a fresh project and the invitee has a separate verified account. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Invite the sample mailbox as viewer, accept from that mailbox account, then open the project.

**Successful postcondition:** The accepted member sees the intended project with viewer capabilities; the owner stays owner.

**Alternative / failure flows:** Remove the tester using the owner account, then retry a protected request from the tester session. Expected: Removed membership grants no further project access, including with the old browser selector. Attempt to remove or demote the sole owner, then use the supported transfer-owner action to the editor. Expected: Removal/demotion cannot leave the project ownerless; a valid transfer makes the new account owner atomically.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-001.

**Acceptance criteria:**

- **AC-004-01** — Given Owner A controls a fresh project and the invitee has a separate verified account. When Invite the sample mailbox as viewer, accept from that mailbox account, then open the project. Then The accepted member sees the intended project with viewer capabilities; the owner stays owner. Verification: TC-010.

- **AC-004-02** — Given An active tester is signed in and can read SAMPLE-A. When Remove the tester using the owner account, then retry a protected request from the tester session. Then Removed membership grants no further project access, including with the old browser selector. Verification: TC-011.

- **AC-004-03** — Given The project has one active owner and a separate editor. When Attempt to remove or demote the sole owner, then use the supported transfer-owner action to the editor. Then Removal/demotion cannot leave the project ownerless; a valid transfer makes the new account owner atomically. Verification: TC-012.

### REQ-005 — Restricted integration keys

**US-005**: As owner / service agent, I need restricted integration keys so that capture and execution integrations can work without receiving human administrator privileges. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Widget and Agent credentials are restricted project service identities, never substitutes for a person or owner membership.

**Source and lineage:** SRC-005 (`pentascope-be/db/runtime.ts`); BR-005 → OBL-005 → REQ-005 → US-005. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/project-access-keys`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** scope: widget:write or agent:execute as issued; raw key: secret returned by controlled issuance only; display: masked last4; revoked status: enforced.

**Preconditions and trigger:** Owner created a Widget key for A; the key is held in a test secret store. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Submit a synthetic issue and attachment through the supported Widget flow, then try listing project requirements with the same key.

**Successful postcondition:** Issue submission follows the Widget contract; requirement access is rejected.

**Alternative / failure flows:** Attempt a member update and owner-only settings change using the Agent key. Expected: The server rejects both actions and membership/settings remain unchanged. Revoke it as owner and retry a supported issue submission with that key. Expected: The revoked key cannot create another issue.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-001.

**Acceptance criteria:**

- **AC-005-01** — Given Owner created a Widget key for A; the key is held in a test secret store. When Submit a synthetic issue and attachment through the supported Widget flow, then try listing project requirements with the same key. Then Issue submission follows the Widget contract; requirement access is rejected. Verification: TC-013.

- **AC-005-02** — Given A valid A Agent key and a separate owner account exist. When Attempt a member update and owner-only settings change using the Agent key. Then The server rejects both actions and membership/settings remain unchanged. Verification: TC-014.

- **AC-005-03** — Given An A Widget key has submitted one known fixture issue. When Revoke it as owner and retry a supported issue submission with that key. Then The revoked key cannot create another issue. Verification: TC-015.

### REQ-006 — Typed document intake and file safety

**US-006**: As editor, I need typed document intake and file safety so that the team analyzes the intended valid document and can identify its exact source version. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Explicit project-owned BRD, SRS and test-case uploads validate type, size and file content before analysis.

**Source and lineage:** SRC-006 (`pentascope-be/app/api/project-documents/route.ts`); BR-006 → OBL-006 → REQ-006 → US-006. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/project-documents`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** documentType: brd/srs/test-cases; file: PDF/DOCX/XLSX/TXT/MD/CSV/JSON/HTML with matching extension/MIME/signature; maximum 20×1024×1024 bytes; hash: content-derived.

**Preconditions and trigger:** A is empty and the tester has reviewed this synthetic BRD and authorized a sandbox import. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Choose BRD, upload BRD.md through the source intake, and inspect the saved source/job entry.

**Successful postcondition:** The source has a project-owned ID, filename, type, content hash and truthful queued/processing state.

**Alternative / failure flows:** Upload the renamed file as PDF; then upload the actual Markdown file as BRD. Expected: The mismatch is rejected with a supported actionable error; the valid document enters the normal intake flow. With analysis disabled/tested through a local harness, submit both sizes using an allowed text MIME and type. Expected: The larger file returns the size rejection; the exact-limit file passes the size gate and remains subject to all other validation.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-006-01** — Given A is empty and the tester has reviewed this synthetic BRD and authorized a sandbox import. When Choose BRD, upload BRD.md through the source intake, and inspect the saved source/job entry. Then The source has a project-owned ID, filename, type, content hash and truthful queued/processing state. Verification: TC-016.

- **AC-006-02** — Given A valid tiny Markdown file and a harmless plain-text file renamed as .pdf are available. When Upload the renamed file as PDF; then upload the actual Markdown file as BRD. Then The mismatch is rejected with a supported actionable error; the valid document enters the normal intake flow. Verification: TC-017.

- **AC-006-03** — Given An isolated local fixture builder can create valid plain-text files at 20 MiB and at 20 MiB + 1 byte; do not send them to a paid provider. When With analysis disabled/tested through a local harness, submit both sizes using an allowed text MIME and type. Then The larger file returns the size rejection; the exact-limit file passes the size gate and remains subject to all other validation. Verification: TC-018.

### REQ-007 — Durable analysis and recovery

**US-007**: As editor / operator, I need durable analysis and recovery so that long-running analysis can recover from failures without losing source identity or duplicating accepted work. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Document work uses durable project-scoped jobs, bounded retries and honest failure states without replacing partial validated work with a misleading summary.

**Source and lineage:** SRC-007 (`pentascope-be/lib/analysis-job-queue.ts`); BR-007 → OBL-007 → REQ-007 → US-007. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/analysis-jobs/[id]`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** jobId: server-issued; attempts: bounded deployed policy; source hash/version: immutable input; progress: observed job progress; retry: authorized action.

**Preconditions and trigger:** A small approved synthetic source is queued and the local worker uses a deterministic provider fixture. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Start the bounded worker, refresh the source status, then open the produced artifact.

**Successful postcondition:** Progress and final state correspond to the durable job; the artifact stays Draft and cites the same source hash.

**Alternative / failure flows:** Process the job, inspect its failure/retry state, then invoke the supported authorized retry. Expected: The job records bounded attempt history; retry preserves source identity and produces at most one successful final artifact version. Run the bounded attempts; if cancellation is offered, request cancellation while queued and observe it. Expected: Exhaustion/cancellation has a truthful terminal state with an actionable reason; no Approved artifact is synthesized.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-004, NFR-008.

**Acceptance criteria:**

- **AC-007-01** — Given A small approved synthetic source is queued and the local worker uses a deterministic provider fixture. When Start the bounded worker, refresh the source status, then open the produced artifact. Then Progress and final state correspond to the durable job; the artifact stays Draft and cites the same source hash. Verification: TC-019.

- **AC-007-02** — Given A test provider fixture fails once with a retryable error, then returns a valid structured draft. When Process the job, inspect its failure/retry state, then invoke the supported authorized retry. Then The job records bounded attempt history; retry preserves source identity and produces at most one successful final artifact version. Verification: TC-020.

- **AC-007-03** — Given A synthetic malformed provider fixture cannot satisfy the artifact schema. When Run the bounded attempts; if cancellation is offered, request cancellation while queued and observe it. Then Exhaustion/cancellation has a truthful terminal state with an actionable reason; no Approved artifact is synthesized. Verification: TC-021.

### REQ-008 — Source obligation coverage and gaps

**US-008**: As requirements manager, I need source obligation coverage and gaps so that no mandatory business obligation disappears between a source document and an approved specification. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Every mandatory source obligation receives an explicit disposition before BRD-derived SRS approval; unsupported assumptions stay visible.

**Source and lineage:** SRC-008 (`pentascope-be/lib/document-analysis-policy.ts`); BR-008 → OBL-008 → REQ-008 → US-008. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/srs-source-audit`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** sourceRef: project artifact/version/hash/locator; disposition: requirement/duplicate/exclusion/ambiguity/conflict; reviewed exclusion: decision required; coverage receipt: current source hash.

**Preconditions and trigger:** A short source states two distinct obligations: only owners can invite; removed members lose access. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Analyze the source using the governed local fixture and inspect the obligation ledger and resulting requirements.

**Successful postcondition:** Both obligations have individual source locators and formal requirement/disposition links; neither is replaced by a generic module summary.

**Alternative / failure flows:** Submit both as versioned project sources and request review. Expected: A conflict is visible with both citations and a blocking decision; the output does not silently choose a permission rule. Change the source by adding a mandatory obligation and process it as a new version. Expected: The old receipt cannot establish complete coverage for the new hash; the new obligation is covered or explicitly listed as a gap.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-002.

**Acceptance criteria:**

- **AC-008-01** — Given A short source states two distinct obligations: only owners can invite; removed members lose access. When Analyze the source using the governed local fixture and inspect the obligation ledger and resulting requirements. Then Both obligations have individual source locators and formal requirement/disposition links; neither is replaced by a generic module summary. Verification: TC-022.

- **AC-008-02** — Given One synthetic source says viewers may edit and another says viewers are read-only. When Submit both as versioned project sources and request review. Then A conflict is visible with both citations and a blocking decision; the output does not silently choose a permission rule. Verification: TC-023.

- **AC-008-03** — Given A source has a complete draft coverage receipt. When Change the source by adding a mandatory obligation and process it as a new version. Then The old receipt cannot establish complete coverage for the new hash; the new obligation is covered or explicitly listed as a gap. Verification: TC-024.

### REQ-009 — Detailed BRD to SRS transformation

**US-009**: As business analyst, I need detailed brd to srs transformation so that reviewers and testers understand exactly how the proposed business behavior should work. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Draft SRS preserves sourced business meaning and supplies actors, flows, data rules, exceptions and observable acceptance criteria without inventing business truth.

**Source and lineage:** SRC-009 (`pentascope-be/skills/pentascope-requirements-to-quality/references/stage-contracts.md`); BR-009 → OBL-009 → REQ-009 → US-009. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/project-documents`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** requirement ID: stable; story: actor/goal/preconditions/trigger/flows/effects; criterion: stable ID and observable expected outcome; claim: sourced/derived/assumption/recommendation/gap.

**Preconditions and trigger:** An approved-to-analyze synthetic BRD contains project invitation scope, actors and expected business result. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Request BRD-to-SRS and inspect the invitation story against the stage contract.

**Successful postcondition:** The draft has source citations, actor, main/alternate/error flows, field validation, permissions, effects and measurable acceptance criteria.

**Alternative / failure flows:** Analyze the source and inspect performance requirements, questions and quality gates. Expected: No invented latency target is presented as sourced; a decision question or explicitly proposed measurable target is returned. Review chapter 2 and inspect document-wide missing-section findings. Expected: The bounded result does not claim unseen chapters are absent; it records only uncertainties evidenced in chapter 2.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-002.

**Acceptance criteria:**

- **AC-009-01** — Given An approved-to-analyze synthetic BRD contains project invitation scope, actors and expected business result. When Request BRD-to-SRS and inspect the invitation story against the stage contract. Then The draft has source citations, actor, main/alternate/error flows, field validation, permissions, effects and measurable acceptance criteria. Verification: TC-025.

- **AC-009-02** — Given The source says the system must be fast but supplies no latency target. When Analyze the source and inspect performance requirements, questions and quality gates. Then No invented latency target is presented as sourced; a decision question or explicitly proposed measurable target is returned. Verification: TC-026.

- **AC-009-03** — Given Only chapter 2 is supplied to a bounded section analysis fixture. When Review chapter 2 and inspect document-wide missing-section findings. Then The bounded result does not claim unseen chapters are absent; it records only uncertainties evidenced in chapter 2. Verification: TC-027.

### REQ-010 — Requirement decisions and immutable revisions

**US-010**: As requirements manager, I need requirement decisions and immutable revisions so that reviewers control what is approved and a concurrent edit cannot silently change that decision. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Explicit authorized review decisions govern requirement status, preserve revision history and invalidate downstream work when source meaning changes.

**Source and lineage:** SRC-010 (`pentascope-be/app/api/requirements-management/route.ts`); BR-010 → OBL-010 → REQ-010 → US-010. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/requirements-management`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** reviewStatus: Draft/Changes Requested/In Review/Approved/Rejected; scopeStatus: In Scope or explicit exclusion; expected version: current management version; reason: meaningful decision rationale.

**Preconditions and trigger:** A draft requirement has complete sources, no open blocking findings and an authorized reviewer under the current decision policy. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Submit for review, inspect gates, then approve with an attributable rationale.

**Successful postcondition:** Only a permitted review transition succeeds; decision actor/time/reason and approved version are recorded.

**Alternative / failure flows:** Submit or attempt the approval action using an authorized manager. Expected: The gate identifies the blocking finding and does not mark the requirement Approved. Save a meaningful change in A; then attempt a different save/decision from B using the original version. Expected: The stale operation is rejected or requires reload; it cannot overwrite A silently.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-010-01** — Given A draft requirement has complete sources, no open blocking findings and an authorized reviewer under the current decision policy. When Submit for review, inspect gates, then approve with an attributable rationale. Then Only a permitted review transition succeeds; decision actor/time/reason and approved version are recorded. Verification: TC-028.

- **AC-010-02** — Given A requirement has an open finding that blocks Approval. When Submit or attempt the approval action using an authorized manager. Then The gate identifies the blocking finding and does not mark the requirement Approved. Verification: TC-029.

- **AC-010-03** — Given Two tabs load the same requirement management version. When Save a meaningful change in A; then attempt a different save/decision from B using the original version. Then The stale operation is rejected or requires reload; it cannot overwrite A silently. Verification: TC-030.

### REQ-011 — Project SRS navigation and explicit links

**US-011**: As viewer, I need project srs navigation and explicit links so that I can find the right story and see which relationships still require a business decision. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** SRS navigation and traceability show only actual project records and preserve unmapped relationships as visible gaps.

**Source and lineage:** SRC-011 (`pentascope-be/app/api/project-traceability/route.ts`); BR-011 → OBL-011 → REQ-011 → US-011. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/en/srs`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** hierarchy: department/module/workflow/story; link: explicit source and target IDs in one project; route/API references: discovered or approved, never invented.

**Preconditions and trigger:** A has a reviewed fixture module, workflow and story with known source markers. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Navigate from the SRS directory to workflow and story, then back to the project view.

**Successful postcondition:** Names, parents, criteria and source links describe the same project-owned story throughout.

**Alternative / failure flows:** Open traceability/coverage and filter for the unmapped record. Expected: The record stays visibly unmapped and is not counted as fully route-covered. Attempt to connect an A test or requirement to the known B story identifier. Expected: The server rejects or omits the unauthorized edge and returns no B content.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-011-01** — Given A has a reviewed fixture module, workflow and story with known source markers. When Navigate from the SRS directory to workflow and story, then back to the project view. Then Names, parents, criteria and source links describe the same project-owned story throughout. Verification: TC-031.

- **AC-011-02** — Given A requirement exists with no confirmed workflow or route. When Open traceability/coverage and filter for the unmapped record. Then The record stays visibly unmapped and is not counted as fully route-covered. Verification: TC-032.

- **AC-011-03** — Given A and B each contain a distinct story; the actor can edit only A. When Attempt to connect an A test or requirement to the known B story identifier. Then The server rejects or omits the unauthorized edge and returns no B content. Verification: TC-033.

### REQ-012 — Story change and language preservation

**US-012**: As editor, I need story change and language preservation so that both language audiences receive the same business meaning and earlier decisions remain traceable. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Story edits and translations preserve source lineage, business obligations and immutable prior meaning; translated content is reviewable.

**Source and lineage:** SRC-012 (`pentascope-be/app/api/story-translate/route.ts`); BR-012 → OBL-012 → REQ-012 → US-012. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/story-edits`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** storyId: project-owned; sourceLanguage/targetLanguage: explicit; text: UTF-8; version and change reason: recorded; identifiers and numeric rules: preserved.

**Preconditions and trigger:** A contains a story with a stable identifier and a known acceptance criterion. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Change its business rule with a reason and inspect the history and impact views.

**Successful postcondition:** The new text is attributable to the editor and previous content remains identifiable.

**Alternative / failure flows:** Request English translation and compare source and translated obligations side by side. Expected: IDs, role restrictions, negation and numeric values are preserved; translation is a reviewable artifact. Request translation and observe the failure; reload the story. Expected: The UI/API report failure and the original story is intact.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-012-01** — Given A contains a story with a stable identifier and a known acceptance criterion. When Change its business rule with a reason and inspect the history and impact views. Then The new text is attributable to the editor and previous content remains identifiable. Verification: TC-034.

- **AC-012-02** — Given The story contains Arabic text, a stable ID and a numeric limit; a local translation fixture is configured. When Request English translation and compare source and translated obligations side by side. Then IDs, role restrictions, negation and numeric values are preserved; translation is a reviewable artifact. Verification: TC-035.

- **AC-012-03** — Given The original bilingual story is persisted and the translation provider fixture returns an error. When Request translation and observe the failure; reload the story. Then The UI/API report failure and the original story is intact. Verification: TC-036.

### REQ-013 — Imported test cases retain identity and quality gaps

**US-013**: As tester, I need imported test cases retain identity and quality gaps so that existing test assets remain reusable without hiding duplicates, missing expectations or unsupported mappings. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Imported cases preserve original identity and content, map only supported requirements and expose duplicates or missing test design fields.

**Source and lineage:** SRC-013 (`pentascope-be/lib/phase1-quality.ts`); BR-013 → OBL-013 → REQ-013 → US-013. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/project-documents`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** documentType: test-cases; external ID: preserved source identity; requirement/criterion links: explicit; steps and expected outcomes: non-empty; review state: Draft.

**Preconditions and trigger:** A CSV fixture contains two distinct original IDs, steps, expected results and source requirement IDs. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Upload as test-cases and inspect the normalized suite.

**Successful postcondition:** Both case identities and detailed steps survive normalization with source lineage and Draft review state.

**Alternative / failure flows:** Import the file and inspect review findings and mapping. Expected: The duplicate and unknown link are visible for review; neither silently inflates verified coverage. Inspect its readiness and attempt to include it in an execution preview. Expected: The case remains non-executable with actionable missing-field reasons.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-013-01** — Given A CSV fixture contains two distinct original IDs, steps, expected results and source requirement IDs. When Upload as test-cases and inspect the normalized suite. Then Both case identities and detailed steps survive normalization with source lineage and Draft review state. Verification: TC-037.

- **AC-013-02** — Given A CSV contains one exact duplicate and a case referencing an unknown requirement. When Import the file and inspect review findings and mapping. Then The duplicate and unknown link are visible for review; neither silently inflates verified coverage. Verification: TC-038.

- **AC-013-03** — Given An imported case has a title but no expected result or usable steps. When Inspect its readiness and attempt to include it in an execution preview. Then The case remains non-executable with actionable missing-field reasons. Verification: TC-039.

### REQ-014 — Risk-based test design and delta generation

**US-014**: As tester, I need risk-based test design and delta generation so that the suite addresses real business risks with reproducible checks and observable outcomes. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Generated tests have distinct risk-based objectives, precise criterion links, reproducible steps and observable outcomes; design does not record execution.

**Source and lineage:** SRC-014 (`pentascope-be/app/api/story-test-generation/route.ts`); BR-014 → OBL-014 → REQ-014 → US-014. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/story-test-generation`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** source case/requirement version: explicit; category: relevant risk dimension; role/data/cleanup/evidence: required for executable design; generation scope: requested delta.

**Preconditions and trigger:** A review-approved invitation requirement has positive and permission criteria; a local structured provider fixture is configured. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Request test design and inspect each returned case and its exact criterion links.

**Successful postcondition:** Cases contain preconditions, independent data, ordered steps, expected outcomes, role and evidence needs, covering distinct business risks.

**Alternative / failure flows:** Request missing coverage for that criterion and inspect the generated delta. Expected: The new case addresses the missing criterion and preserves the existing reviewed case/version. Run generation through the backend validator. Expected: Invalid links cannot enter approved coverage; the job reports a validation gap or bounded correction.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-002.

**Acceptance criteria:**

- **AC-014-01** — Given A review-approved invitation requirement has positive and permission criteria; a local structured provider fixture is configured. When Request test design and inspect each returned case and its exact criterion links. Then Cases contain preconditions, independent data, ordered steps, expected outcomes, role and evidence needs, covering distinct business risks. Verification: TC-040.

- **AC-014-02** — Given The suite already has a reviewed happy-path case but lacks the revoked-member criterion. When Request missing coverage for that criterion and inspect the generated delta. Then The new case addresses the missing criterion and preserves the existing reviewed case/version. Verification: TC-041.

- **AC-014-03** — Given A provider fixture returns a case referencing a nonexistent requirement or criterion. When Run generation through the backend validator. Then Invalid links cannot enter approved coverage; the job reports a validation gap or bounded correction. Verification: TC-042.

### REQ-015 — Test library selection and approval readiness

**US-015**: As tester, I need test library selection and approval readiness so that I can choose an accurate current scope and know which cases still need preparation. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Selections resolve current project-owned cases and distinguish approved browser-ready, blocked and manual-only work.

**Source and lineage:** SRC-015 (`pentascope-be/lib/test-library.ts`); BR-015 → OBL-015 → REQ-015 → US-015. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/test-case-groups`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** selection: explicit IDs or current filter/group; case version: current; execution mode: manual/browser; approval state: current; status totals: disjoint truthful counts.

**Preconditions and trigger:** A has distinguishable module suites with different priorities and review states. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Apply a module and priority filter, select the visible scope, then inspect selected IDs/counts.

**Successful postcondition:** Selection contains only matching project cases; hidden stale selections are not silently included.

**Alternative / failure flows:** Request execution preview with the entire selection and no run-ready-only opt-in. Expected: The preview returns an explicit mixed-selection blocker with ready/blocked/manual counts. Change the linked requirement through the permitted workflow, then resolve the old case selection. Expected: The selection cannot treat the stale approval as current execution readiness.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-015-01** — Given A has distinguishable module suites with different priorities and review states. When Apply a module and priority filter, select the visible scope, then inspect selected IDs/counts. Then Selection contains only matching project cases; hidden stale selections are not silently included. Verification: TC-043.

- **AC-015-02** — Given The selection contains one approved browser case, one Draft case and one manual-only case. When Request execution preview with the entire selection and no run-ready-only opt-in. Then The preview returns an explicit mixed-selection blocker with ready/blocked/manual counts. Verification: TC-044.

- **AC-015-03** — Given A case was approved against requirement version 1. When Change the linked requirement through the permitted workflow, then resolve the old case selection. Then The selection cannot treat the stale approval as current execution readiness. Verification: TC-045.

### REQ-016 — Execution preview bound to target and versions

**US-016**: As tester, I need execution preview bound to target and versions so that the browser runs exactly the cases, target and role I reviewed before confirmation. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** A confirmed preview binds selected cases, membership version, target and credentials; changes require fresh review before queueing.

**Source and lineage:** SRC-016 (`pentascope-be/app/api/execution-previews/route.ts`); BR-016 → OBL-016 → REQ-016 → US-016. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/execution-previews`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** previewId/hash: server-issued; target: approved base URL/environment; options: credentialId/role/mode/dataProfile; selected case versions: frozen by preview.

**Preconditions and trigger:** A has one approved browser-ready case, a configured sandbox target and an authorized tester. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Preview the case, review the target/role/counts, then confirm using the returned preview contract.

**Successful postcondition:** A command corresponds exactly to the reviewed case and target; it is not shown as already executed.

**Alternative / failure flows:** Change the project target or selected credential state, then attempt to confirm the old preview. Expected: The stale preview cannot queue execution against the changed target; a fresh preview is required. Revoke the tester or change case approval/version before confirmation; retry using the original preview. Expected: Current authorization and version checks reject the stale confirmation.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-016-01** — Given A has one approved browser-ready case, a configured sandbox target and an authorized tester. When Preview the case, review the target/role/counts, then confirm using the returned preview contract. Then A command corresponds exactly to the reviewed case and target; it is not shown as already executed. Verification: TC-046.

- **AC-016-02** — Given A valid preview exists but has not been confirmed. When Change the project target or selected credential state, then attempt to confirm the old preview. Then The stale preview cannot queue execution against the changed target; a fresh preview is required. Verification: TC-047.

- **AC-016-03** — Given A tester holds a preview for case version 1. When Revoke the tester or change case approval/version before confirmation; retry using the original preview. Then Current authorization and version checks reject the stale confirmation. Verification: TC-048.

### REQ-017 — Credential storage and scoped leases

**US-017**: As owner / service agent, I need credential storage and scoped leases so that an authorized runner can authenticate without exposing stored credentials to ordinary project readers. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Test credentials are encrypted server-side and leased only through authorized Agent execution scope; ordinary reads expose metadata only.

**Source and lineage:** SRC-017 (`pentascope-be/app/api/project-credentials/[id]/lease/route.ts`); BR-017 → OBL-017 → REQ-017 → US-017. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/project-credentials/[id]/lease`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** credentialId: project-owned; login URL: target context; password: never stored in this pack/logs; status: Ready before selection; lease: short-lived server policy.

**Preconditions and trigger:** Owner has a tester-controlled sandbox account; only the secret store contains its password. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Create a credential using the HTTPS project flow, then list credential metadata and inspect browser storage.

**Successful postcondition:** The credential is selectable by reference and list/UI/storage do not expose the password.

**Alternative / failure flows:** Request its lease using each disallowed identity. Expected: Both requests are denied without credential material. Request B credential with A Agent, then revoke an A credential and request that lease. Expected: Neither foreign nor revoked credential can be leased.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-001, NFR-003.

**Acceptance criteria:**

- **AC-017-01** — Given Owner has a tester-controlled sandbox account; only the secret store contains its password. When Create a credential using the HTTPS project flow, then list credential metadata and inspect browser storage. Then The credential is selectable by reference and list/UI/storage do not expose the password. Verification: TC-049.

- **AC-017-02** — Given A ready A credential exists; viewer and Widget identities have no Agent scope. When Request its lease using each disallowed identity. Then Both requests are denied without credential material. Verification: TC-050.

- **AC-017-03** — Given The Agent belongs to A and a distinct B credential identifier is known in the isolated fixture. When Request B credential with A Agent, then revoke an A credential and request that lease. Then Neither foreign nor revoked credential can be leased. Verification: TC-051.

### REQ-018 — Command claims, progress and recovery

**US-018**: As agent:execute, I need command claims, progress and recovery so that approved work completes once with truthful progress even when an agent stops or competes for a claim. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Agents execute only authorized safe commands, keep attributable progress and recover from interruption without duplicate terminal results.

**Source and lineage:** SRC-018 (`pentascope-be/lib/test-command-service.ts`); BR-018 → OBL-018 → REQ-018 → US-018. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/test-commands`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** commandId: server-issued; claim/lease: server-enforced; case IDs and target: approved; state: persisted; step timestamp: actual; forbidden actions: configured safe-mode policy.

**Preconditions and trigger:** An authorized command contains one approved read-only browser case and an Agent key for A. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Claim it through the supported agent flow, perform the prescribed steps and submit actual receipts.

**Successful postcondition:** The command moves through truthful progress to its computed terminal state and is linked to its real run.

**Alternative / failure flows:** Have both clients attempt to claim the same command at the same time. Expected: Only a valid current claimant may perform/complete the command; no duplicate authoritative run is accepted. Interrupt the client before completion, allow the configured lease/recovery action, then resume through the supported flow. Expected: Progress remains distinguishable from success; recovery cannot manufacture missing step evidence.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-004, NFR-008.

**Acceptance criteria:**

- **AC-018-01** — Given An authorized command contains one approved read-only browser case and an Agent key for A. When Claim it through the supported agent flow, perform the prescribed steps and submit actual receipts. Then The command moves through truthful progress to its computed terminal state and is linked to its real run. Verification: TC-052.

- **AC-018-02** — Given One unclaimed command and two isolated authorized Agent clients exist. When Have both clients attempt to claim the same command at the same time. Then Only a valid current claimant may perform/complete the command; no duplicate authoritative run is accepted. Verification: TC-053.

- **AC-018-03** — Given An Agent has claimed a safe read-only command; the recovery timing policy is recorded. When Interrupt the client before completion, allow the configured lease/recovery action, then resume through the supported flow. Then Progress remains distinguishable from success; recovery cannot manufacture missing step evidence. Verification: TC-054.

### REQ-019 — Verifiable assertions and private evidence

**US-019**: As agent:execute / tester, I need verifiable assertions and private evidence so that release reviewers can trust a result because actual observations prove its assertions. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** The backend computes assertion outcomes from actual receipts and never accepts an unsupported pass; evidence is project-scoped and expires by policy.

**Source and lineage:** SRC-019 (`pentascope-be/lib/execution-evidence.ts`); BR-019 → OBL-019 → REQ-019 → US-019. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/test-runs`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** assertion: ID/kind/subject/operator/expected/sourceRef; receipt: actual/outcome/observedAt; steps: ordered actual observations; files: private signed access; case version: exact.

**Preconditions and trigger:** An approved safe test expects a specific page text and URL on the sandbox build. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Execute it and submit actual step receipts plus matching objective assertions and allowed evidence.

**Successful postcondition:** The recorded outcome is computed from the actual observations and links to the exact case/build.

**Alternative / failure flows:** Submit actual=500 with a client-reported Passed result through the local execution harness. Expected: The backend does not record an authoritative pass; computed outcome or validation identifies the mismatch. Try a modified signature, an unauthorized project context and the URL after expiry. Expected: Access is denied without exposing object credentials or a reusable private storage location.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-001, NFR-002.

**Acceptance criteria:**

- **AC-019-01** — Given An approved safe test expects a specific page text and URL on the sandbox build. When Execute it and submit actual step receipts plus matching objective assertions and allowed evidence. Then The recorded outcome is computed from the actual observations and links to the exact case/build. Verification: TC-055.

- **AC-019-02** — Given The assertion contract expects HTTP status 200; a controlled target returns 500. When Submit actual=500 with a client-reported Passed result through the local execution harness. Then The backend does not record an authoritative pass; computed outcome or validation identifies the mismatch. Verification: TC-056.

- **AC-019-03** — Given A private evidence file exists and the configured signed-URL expiry is recorded. When Try a modified signature, an unauthorized project context and the URL after expiry. Then Access is denied without exposing object credentials or a reusable private storage location. Verification: TC-057.

### REQ-020 — Defect capture and human triage

**US-020**: As tester / editor, I need defect capture and human triage so that the team can reproduce reported problems and make accountable decisions about which need fixes. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Defects record reproducible observations and evidence; authorized human decisions separate confirmed fixes from rejected reports.

**Source and lineage:** SRC-020 (`pentascope-be/app/api/issues/[id]/route.ts`); BR-020 → OBL-020 → REQ-020 → US-020. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/issues`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** issueId: server-issued; source run/case: actual if available; actual vs expected: separate; severity: triaged impact; status/reason/actor: attributable.

**Preconditions and trigger:** A controlled sandbox page displays a wrong label; the expected label is linked to a reviewed criterion. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Create an issue with reproduction steps, actual/expected text, target build and redacted screenshot.

**Successful postcondition:** The issue retains the supplied facts and links without asserting unobserved impact.

**Alternative / failure flows:** Use an authorized decision role to approve the first for fix and reject the second with rationale. Expected: Each decision follows an allowed transition with an attributable business reason. Attempt to change it directly to Closed using the disallowed identity. Expected: The transition is rejected and the original status remains.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-008.

**Acceptance criteria:**

- **AC-020-01** — Given A controlled sandbox page displays a wrong label; the expected label is linked to a reviewed criterion. When Create an issue with reproduction steps, actual/expected text, target build and redacted screenshot. Then The issue retains the supplied facts and links without asserting unobserved impact. Verification: TC-058.

- **AC-020-02** — Given Two fixture issues exist: one reproducible and one contradicted by the approved requirement. When Use an authorized decision role to approve the first for fix and reject the second with rationale. Then Each decision follows an allowed transition with an attributable business reason. Verification: TC-059.

- **AC-020-03** — Given An issue is open and a viewer or Widget key can identify it within the fixture. When Attempt to change it directly to Closed using the disallowed identity. Then The transition is rejected and the original status remains. Verification: TC-060.

### REQ-021 — Fix delivery and exact-build retest

**US-021**: As editor / tester, I need fix delivery and exact-build retest so that a closed defect means its actual delivered fix has been verified on the correct build. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** A defect cannot close until a verified fully passing retest proves the fix on the delivered build and correct case lineage.

**Source and lineage:** SRC-020 (`pentascope-be/app/api/issues/[id]/route.ts`); BR-021 → OBL-021 → REQ-021 → US-021. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/issues/[id]`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** fix build: exact revision/identifier; delivery reference: durable link; retest run: project-owned, verified and fully passing; case lineage: issue-related; closure: named decision.

**Preconditions and trigger:** A confirmed issue is approved for fix and a real sandbox fix build is available. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Record the exact build and delivery reference using the supported fix transition.

**Successful postcondition:** The issue records the build/delivery and reaches the allowed retest state, without claiming the fix passed.

**Alternative / failure flows:** Attempt closure using the unrelated or wrong-build run. Expected: The gate rejects closure and explains the mismatched evidence. Run the case and required regression on that exact build; submit receipts; close through the authorized workflow. Expected: Closure succeeds only if the required run is fully passing and evidence/lineage/build match.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-008.

**Acceptance criteria:**

- **AC-021-01** — Given A confirmed issue is approved for fix and a real sandbox fix build is available. When Record the exact build and delivery reference using the supported fix transition. Then The issue records the build/delivery and reaches the allowed retest state, without claiming the fix passed. Verification: TC-061.

- **AC-021-02** — Given The issue awaits retest on build A; a passing fixture run exists on build B or unrelated case lineage. When Attempt closure using the unrelated or wrong-build run. Then The gate rejects closure and explains the mismatched evidence. Verification: TC-062.

- **AC-021-03** — Given The actual fix build is deployed in the isolated target and a linked approved case is ready. When Run the case and required regression on that exact build; submit receipts; close through the authorized workflow. Then Closure succeeds only if the required run is fully passing and evidence/lineage/build match. Verification: TC-063.

### REQ-022 — Change impact and regression selection

**US-022**: As editor, I need change impact and regression selection so that the team retests affected behavior and can see where incomplete links leave uncertainty. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Impact derives from explicit current links and identifies affected requirements, cases and downstream records without hiding unknown relationships.

**Source and lineage:** SRC-021 (`pentascope-be/lib/project-impact-engine.ts`); BR-022 → OBL-022 → REQ-022 → US-022. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/project-impact`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** change reference: exact version; edge: persisted traceability; affected IDs: project-owned; rationale: cited link or labelled uncertainty; regression decision: human-reviewed.

**Preconditions and trigger:** A requirement links to two cases and an unrelated requirement links to a third. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Change the first requirement meaningfully and inspect impact.

**Successful postcondition:** Both linked cases appear with traceable reasons; the unrelated case is not falsely asserted to depend on the changed rule.

**Alternative / failure flows:** Request impact and inspect coverage/gaps. Expected: The response identifies missing mappings and cannot claim no impact merely because no link exists. Ask about the change in A using a local response fixture and inspect answer citations. Expected: Citations resolve to A records; unsupported consequences are marked uncertain.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-022-01** — Given A requirement links to two cases and an unrelated requirement links to a third. When Change the first requirement meaningfully and inspect impact. Then Both linked cases appear with traceable reasons; the unrelated case is not falsely asserted to depend on the changed rule. Verification: TC-064.

- **AC-022-02** — Given A changed requirement lacks route or case links. When Request impact and inspect coverage/gaps. Then The response identifies missing mappings and cannot claim no impact merely because no link exists. Verification: TC-065.

- **AC-022-03** — Given A and B contain different similarly named requirements; A has only one accessible source. When Ask about the change in A using a local response fixture and inspect answer citations. Then Citations resolve to A records; unsupported consequences are marked uncertain. Verification: TC-066.

### REQ-023 — Coverage arithmetic and release decisions

**US-023**: As owner, I need coverage arithmetic and release decisions so that the release owner can distinguish planned coverage from observed proof and unresolved critical risk. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Designed, approved, executed, passed and evidenced coverage are separate measurements; critical gaps block release despite a high aggregate score.

**Source and lineage:** SRC-022 (`pentascope-be/app/api/lifecycle/route.ts`); BR-023 → OBL-023 → REQ-023 → US-023. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/lifecycle`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** denominator: in-scope current requirement/criterion IDs; numerator: explicit qualifying links; run/build: exact; dimension: functional/security/API/etc.; decision: named and reasoned.

**Preconditions and trigger:** A has four in-scope criteria, two linked Draft cases and no runs. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Open traceability and release/coverage views.

**Successful postcondition:** Designed criterion coverage is 2/4 where explicit links exist; executed/passed coverage remains zero.

**Alternative / failure flows:** Prepare a release readiness decision for that exact build. Expected: The unresolved critical criterion blocks a ready/approved conclusion regardless of average score. Revise a linked requirement and inspect readiness for the changed scope/current build. Expected: The prior assessment stays historical and cannot count as current proof of the changed obligation.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-002.

**Acceptance criteria:**

- **AC-023-01** — Given A has four in-scope criteria, two linked Draft cases and no runs. When Open traceability and release/coverage views. Then Designed criterion coverage is 2/4 where explicit links exist; executed/passed coverage remains zero. Verification: TC-067.

- **AC-023-02** — Given Most cases have valid passing evidence but a critical tenant-isolation criterion has no accepted run. When Prepare a release readiness decision for that exact build. Then The unresolved critical criterion blocks a ready/approved conclusion regardless of average score. Verification: TC-068.

- **AC-023-03** — Given A previous build has a recorded readiness assessment. When Revise a linked requirement and inspect readiness for the changed scope/current build. Then The prior assessment stays historical and cannot count as current proof of the changed obligation. Verification: TC-069.

### REQ-024 — Portable exports and controlled handoff

**US-024**: As owner / editor, I need portable exports and controlled handoff so that another reviewer can follow the same quality lineage without receiving private credentials. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Exports and handoffs retain IDs, versions, status and project lineage while excluding secrets and unsupported readiness claims.

**Source and lineage:** SRC-023 (`pentascope-be/app/api/validation-transfer/route.ts`); BR-024 → OBL-024 → REQ-024 → US-024. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/validation-transfer`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** export project/version: explicit; case IDs: stable; status: truthful; evidence: authorized references; credentials/raw tokens: excluded; destination: authorized when transfer is requested.

**Preconditions and trigger:** A has a versioned source, requirement, Draft case and no execution. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Use the supported export/handoff operation and inspect the downloaded artifact.

**Successful postcondition:** The artifact preserves IDs, links and Draft/Not Run meaning with a visible project/version.

**Alternative / failure flows:** Export project handoff and inspect allowed metadata with an approved redaction scanner. Expected: No credential password, raw service key, provider key or storage secret is present. Attempt B export/validation transfer with A authorization. Expected: The server denies export without leaking B records or generating a downloadable B artifact.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-003.

**Acceptance criteria:**

- **AC-024-01** — Given A has a versioned source, requirement, Draft case and no execution. When Use the supported export/handoff operation and inspect the downloaded artifact. Then The artifact preserves IDs, links and Draft/Not Run meaning with a visible project/version. Verification: TC-070.

- **AC-024-02** — Given A has a credential and service key with unique secret markers held outside the pack. When Export project handoff and inspect allowed metadata with an approved redaction scanner. Then No credential password, raw service key, provider key or storage secret is present. Verification: TC-071.

- **AC-024-03** — Given A-only member knows B project ID in the isolated fixture. When Attempt B export/validation transfer with A authorization. Then The server denies export without leaking B records or generating a downloadable B artifact. Verification: TC-072.

### REQ-025 — Scheduled execution with renewed readiness

**US-025**: As owner, I need scheduled execution with renewed readiness so that recurring tests run only while their scope, permissions and target remain valid. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Schedules are project-owned, use validated cases/targets and do not execute stale or unauthorized work after relevant state changes.

**Source and lineage:** SRC-024 (`pentascope-be/app/api/test-schedules/route.ts`); BR-025 → OBL-025 → REQ-025 → US-025. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/test-schedules`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** name: required; cases/routes: at least one validated item; intervalMinutes: current route normalizes to 15–10080; status: active/paused; next run: ISO timestamp.

**Preconditions and trigger:** A has one approved safe case and the local dispatcher is controlled by the tester. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Create a schedule, inspect next-run metadata, then pause before it is due.

**Successful postcondition:** The schedule belongs to A with validated selection and a visible paused state.

**Alternative / failure flows:** Attempt schedules for each invalid selection and an empty name/selection. Expected: Invalid requests report actionable errors and cannot create executable scheduled work. Change the approval/membership, then try resuming and dispatching it. Expected: Current authorization/readiness is enforced; stale scheduling data cannot bypass execution gates.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-004.

**Acceptance criteria:**

- **AC-025-01** — Given A has one approved safe case and the local dispatcher is controlled by the tester. When Create a schedule, inspect next-run metadata, then pause before it is due. Then The schedule belongs to A with validated selection and a visible paused state. Verification: TC-073.

- **AC-025-02** — Given A has a Draft case and an unknown case ID. When Attempt schedules for each invalid selection and an empty name/selection. Then Invalid requests report actionable errors and cannot create executable scheduled work. Verification: TC-074.

- **AC-025-03** — Given A paused schedule was valid before its case approval or creator membership changed. When Change the approval/membership, then try resuming and dispatching it. Then Current authorization/readiness is enforced; stale scheduling data cannot bypass execution gates. Verification: TC-075.

### REQ-026 — Safe webhook delivery and retry

**US-026**: As owner / operator, I need safe webhook delivery and retry so that approved integrations receive events reliably and failed delivery remains visible for recovery. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Webhook destinations follow exact-host outbound policy and delivery/retry state records actual transport outcomes.

**Source and lineage:** SRC-025 (`pentascope-be/lib/webhook-delivery.ts`); BR-026 → OBL-026 → REQ-026 → US-026. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/webhook-deliveries`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** destination: approved HTTPS host; redirects/private addresses: governed deny policy; event ID: stable; attempts: bounded; payload: project-scoped and redacted.

**Preconditions and trigger:** A local isolated transport fixture simulates an approved HTTPS webhook sink; no real recipient is used. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Trigger a supported project event and process one delivery pass.

**Successful postcondition:** A delivery record links the event to its actual accepted response and attempt time.

**Alternative / failure flows:** Through the local transport harness test non-allowlisted, loopback/private and redirecting destinations. Expected: Unsafe destinations are rejected before forbidden network access; redirect policy is enforced. Process the first attempt and inspect failure, then process the due retry. Expected: The first attempt is failed/pending retry; only the accepted receipt establishes delivery.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-004.

**Acceptance criteria:**

- **AC-026-01** — Given A local isolated transport fixture simulates an approved HTTPS webhook sink; no real recipient is used. When Trigger a supported project event and process one delivery pass. Then A delivery record links the event to its actual accepted response and attempt time. Verification: TC-076.

- **AC-026-02** — Given The outbound policy uses a fixture allowlist and no external request is needed. When Through the local transport harness test non-allowlisted, loopback/private and redirecting destinations. Then Unsafe destinations are rejected before forbidden network access; redirect policy is enforced. Verification: TC-077.

- **AC-026-03** — Given The fixture sink returns a retryable failure once then accepts the same event. When Process the first attempt and inspect failure, then process the due retry. Then The first attempt is failed/pending retry; only the accepted receipt establishes delivery. Verification: TC-078.

### REQ-027 — Grounded and bounded assistant plans

**US-027**: As tester, I need grounded and bounded assistant plans so that the assistant helps plan safe project work using known sources and identifies what is missing. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Agent plans use authenticated project sources and allowed targets, explain missing inputs and stay within the approved safe execution mission.

**Source and lineage:** SRC-026 (`pentascope-be/app/api/agent/plan/route.ts`); BR-027 → OBL-027 → REQ-027 → US-027. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/agent/plan`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** mission: explicit goal/scope; target: authorized base URL/route; role: credential reference; source IDs: project-owned; unsafe actions: forbidden unless explicitly approved in execution policy.

**Preconditions and trigger:** A has an approved read-only scenario, route map and local provider fixture. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Request an agent plan and inspect its steps, source links and target.

**Successful postcondition:** Steps are executable within the known route/role, cite the project source and contain observable assertions.

**Alternative / failure flows:** Request execution-oriented planning for an authenticated journey. Expected: The response identifies the missing prerequisite and cannot represent the plan as execution-ready. Run planning with the document as untrusted source content through a local provider fixture. Expected: The quoted instructions are treated as source data and do not change scope, reveal secrets or trigger outbound actions.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-002.

**Acceptance criteria:**

- **AC-027-01** — Given A has an approved read-only scenario, route map and local provider fixture. When Request an agent plan and inspect its steps, source links and target. Then Steps are executable within the known route/role, cite the project source and contain observable assertions. Verification: TC-079.

- **AC-027-02** — Given A lacks a confirmed target URL or required role credential. When Request execution-oriented planning for an authenticated journey. Then The response identifies the missing prerequisite and cannot represent the plan as execution-ready. Verification: TC-080.

- **AC-027-03** — Given A synthetic document contains quoted text telling the assistant to reveal secrets and visit an unrelated domain. When Run planning with the document as untrusted source content through a local provider fixture. Then The quoted instructions are treated as source data and do not change scope, reveal secrets or trigger outbound actions. Verification: TC-081.

### REQ-028 — Governed AI output, privacy and budgets

**US-028**: As owner / operator, I need governed ai output, privacy and budgets so that the team receives validated AI work within approved privacy and spending boundaries. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** AI operations use task-specific policy, validated structured output, bounded provider attempts and usage metadata without saving source bodies or secrets in usage receipts.

**Source and lineage:** SRC-027 (`pentascope-be/lib/ai-task-registry.ts`); BR-028 → OBL-028 → REQ-028 → US-028. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/ai-factory`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** operation/skill version: registered; source hash: current; provider/model: governed route; usage: tokens/cost/latency metadata; budget: enforced server-side; cache: scoped/versioned.

**Preconditions and trigger:** A valid deterministic provider fixture is configured and external paid requests are disabled. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Run a bounded test-design request and open owner-visible usage metadata.

**Successful postcondition:** The receipt identifies operation, policy/model fixture, counts and outcome without storing prompt/source/response bodies.

**Alternative / failure flows:** Request another AI operation without changing the server policy. Expected: The backend reports a budget/policy block before an unauthorized provider call. Run the operation and inspect attempt/error receipts. Expected: Only allowed bounded attempts occur; invalid fallback output cannot become an approved artifact or fake successful answer.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-003.

**Acceptance criteria:**

- **AC-028-01** — Given A valid deterministic provider fixture is configured and external paid requests are disabled. When Run a bounded test-design request and open owner-visible usage metadata. Then The receipt identifies operation, policy/model fixture, counts and outcome without storing prompt/source/response bodies. Verification: TC-082.

- **AC-028-02** — Given An isolated policy fixture has exhausted its allowed project/operation budget. When Request another AI operation without changing the server policy. Then The backend reports a budget/policy block before an unauthorized provider call. Verification: TC-083.

- **AC-028-03** — Given The first fixture provider fails and one permitted fallback returns malformed JSON. When Run the operation and inspect attempt/error receipts. Then Only allowed bounded attempts occur; invalid fallback output cannot become an approved artifact or fake successful answer. Verification: TC-084.

### REQ-029 — Private generated media and real content validation

**US-029**: As editor, I need private generated media and real content validation so that the team can use real private presentation images without confusing them with test evidence. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Generated presentation images are real validated media stored privately in the selected project and are never evidence of a test execution.

**Source and lineage:** SRC-028 (`pentascope-be/app/api/ai-images/route.ts`); BR-029 → OBL-029 → REQ-029 → US-029. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/ai-images`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** image content: valid PNG/JPEG/WebP; source context: authorized; storage: private S3-compatible; read URL: signed/expiring; usage: governed image operation.

**Preconditions and trigger:** The local image provider fixture returns a small valid PNG and private sandbox storage is available. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Request a project presentation image, then open its authorized signed URL.

**Successful postcondition:** The image decodes correctly, belongs to A and has generation/usage metadata.

**Alternative / failure flows:** Request generation and inspect the result. Expected: Content validation rejects the payload and does not publish a broken/private artifact as success. Try unauthorized metadata access and then access after configured link expiry. Expected: Unauthorized metadata and expired reads are denied; the private object remains controlled.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: review the relevant adopted NFRs.

**Acceptance criteria:**

- **AC-029-01** — Given The local image provider fixture returns a small valid PNG and private sandbox storage is available. When Request a project presentation image, then open its authorized signed URL. Then The image decodes correctly, belongs to A and has generation/usage metadata. Verification: TC-085.

- **AC-029-02** — Given The fixture provider returns HTML or invalid bytes while labelling them image/png. When Request generation and inspect the result. Then Content validation rejects the payload and does not publish a broken/private artifact as success. Verification: TC-086.

- **AC-029-03** — Given A generated image has a valid signed URL and B has no access to A. When Try unauthorized metadata access and then access after configured link expiry. Then Unauthorized metadata and expired reads are denied; the private object remains controlled. Verification: TC-087.

### REQ-030 — Accessible bilingual and responsive workspace

**US-030**: As viewer / tester, I need accessible bilingual and responsive workspace so that Arabic and English users can complete core work on narrow screens and with a keyboard. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** English and Arabic routes preserve task context; core controls remain usable by keyboard and in narrow screens with accurate loading, empty and error states.

**Source and lineage:** SRC-029 (`pentascope-fe/lib/localized-route.mjs`); BR-030 → OBL-030 → REQ-030 → US-030. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/en/srs and /srs`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** language: en/ar; Arabic direction: rtl; English: ltr; viewport fixtures: 375 and 1440 CSS pixels; focused control: visible; accessible name: meaningful.

**Preconditions and trigger:** A contains English and Arabic source/story titles and the viewer is signed in. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Open /en/srs, switch to Arabic, navigate to a story, then return to English.

**Successful postcondition:** Authorized project context and corresponding content are preserved; direction and labels match the selected language.

**Alternative / failure flows:** Navigate with Tab/Shift+Tab, activate labelled buttons and open/close any dialog using keyboard controls. Expected: Focus is visible and logical; controls have accessible names; dialogs do not trap or lose focus incorrectly. At 375 CSS pixels open Arabic and English project/SRS views; then trigger the controlled load failure and retry. Expected: Important content/actions remain readable without clipped controls; empty, loading and error states are distinct and retryable.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-005.

**Acceptance criteria:**

- **AC-030-01** — Given A contains English and Arabic source/story titles and the viewer is signed in. When Open /en/srs, switch to Arabic, navigate to a story, then return to English. Then Authorized project context and corresponding content are preserved; direction and labels match the selected language. Verification: TC-088.

- **AC-030-02** — Given A tester can access source intake and the review/library controls in a desktop browser. When Navigate with Tab/Shift+Tab, activate labelled buttons and open/close any dialog using keyboard controls. Then Focus is visible and logical; controls have accessible names; dialogs do not trap or lose focus incorrectly. Verification: TC-089.

- **AC-030-03** — Given A is empty and a controlled backend-error fixture can be enabled. When At 375 CSS pixels open Arabic and English project/SRS views; then trigger the controlled load failure and retry. Then Important content/actions remain readable without clipped controls; empty, loading and error states are distinct and retryable. Verification: TC-090.

### REQ-031 — Readiness, backups and recovery operations

**US-031**: As operator, I need readiness, backups and recovery operations so that operators can detect dependency failures and recover a consistent set of business records and evidence. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Operations distinguish process liveness from required data/storage readiness and validate recovery against a consistent isolated database/object-store snapshot.

**Source and lineage:** SRC-030 (`pentascope-be/app/api/ready/route.ts`); BR-031 → OBL-031 → REQ-031 → US-031. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/health and /api/ready`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** health: process status; ready: MySQL and object storage checks; build: exact revision; backup manifest: database and object-store point; RPO/RTO: owner decision, not inferred.

**Preconditions and trigger:** The isolated API, migrated database and private object storage are available. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Request liveness and readiness; inspect dependency outcomes and timestamps.

**Successful postcondition:** Liveness confirms the process and readiness reports dependency availability without credentials.

**Alternative / failure flows:** Disable one dependency, request both probes, then restore it. Expected: Readiness reports the affected dependency failure; liveness remains a distinct process signal. Restore into a new disposable namespace, run migration/readiness checks and open the linked artifact/evidence. Expected: The restored graph and evidence agree on IDs/versions; original environment is unchanged.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-006, NFR-007.

**Acceptance criteria:**

- **AC-031-01** — Given The isolated API, migrated database and private object storage are available. When Request liveness and readiness; inspect dependency outcomes and timestamps. Then Liveness confirms the process and readiness reports dependency availability without credentials. Verification: TC-091.

- **AC-031-02** — Given An operator-controlled local fixture can disable MySQL or storage without touching shared services. When Disable one dependency, request both probes, then restore it. Then Readiness reports the affected dependency failure; liveness remains a distinct process signal. Verification: TC-092.

- **AC-031-03** — Given An approved isolated backup contains a sample source, case, run metadata and matching evidence object; restoration is explicitly authorized for the sandbox. When Restore into a new disposable namespace, run migration/readiness checks and open the linked artifact/evidence. Then The restored graph and evidence agree on IDs/versions; original environment is unchanged. Verification: TC-093.

### REQ-032 — Auditability and sensitive-data minimization

**US-032**: As owner / operator, I need auditability and sensitive-data minimization so that the team can investigate changes and failures without leaking project content or secrets. Priority P1; risk High; state Draft; classification recommendation.

**Requirement:** Business mutations and failures remain attributable to project, actor, operation and time while operational views exclude secret/source-body leakage.

**Source and lineage:** SRC-031 (`pentascope-be/lib/system-log.ts`); BR-032 → OBL-032 → REQ-032 → US-032. Proposed synthetic acceptance contract grounded in the cited local implementation/skill surface; it is not an approved customer requirement or proof of deployed behavior.

**Target surface:** `/api/activity and /api/system-logs`. Bind actual deployed URL/build and request schema before execution; a discovered source path is not proof of current deployment.

**Fields and validation:** activity: project/actor/module/operation/time; correlation: command/run/job/issue where relevant; logs: sanitized; filters: bounded project scope; retention: approved policy gap.

**Preconditions and trigger:** A named requirements manager has a review-ready requirement. The actor initiates the specific action below after scope/identity readiness.

**Main flow:** Record a permitted review decision, then inspect activity and requirement decision history.

**Successful postcondition:** Project, actor, action, time and affected requirement/version can be reconciled.

**Alternative / failure flows:** Trigger the failure and inspect user-visible errors, system logs and usage metadata. Expected: Actionable failure context remains while sensitive header/key/source-body values are redacted. As A query and paginate activity/log filters, including a guessed B identifier. Expected: Only authorized A data is returned; counts and pagination do not reveal B content.

**Permissions and data effects:** Enforce the current named-member capability or restricted service scope on the backend; reject foreign IDs and stale ownership. Reads do not mutate unrelated records. Mutations preserve a reviewable actor/project/version/time record where applicable. No source or secret is allowed to enter an unrelated project.

**Notifications / integrations:** Follow only this scenario's actual operation: use the controlled mail sink for identity/invitations, worker/provider fixtures for analysis/AI, transport fixtures for webhooks, and private storage fixtures for evidence/media. Record Not applicable for operations that trigger none.

**Dependencies / open decisions:** GAP-001, GAP-002, GAP-007, GAP-009; apply field-specific open decisions before approving. Proposed NFRs: NFR-003, NFR-008.

**Acceptance criteria:**

- **AC-032-01** — Given A named requirements manager has a review-ready requirement. When Record a permitted review decision, then inspect activity and requirement decision history. Then Project, actor, action, time and affected requirement/version can be reconciled. Verification: TC-094.

- **AC-032-02** — Given A local transport fixture throws an error containing harmless canary text representing a secret. When Trigger the failure and inspect user-visible errors, system logs and usage metadata. Then Actionable failure context remains while sensitive header/key/source-body values are redacted. Verification: TC-095.

- **AC-032-03** — Given A and B each contain a uniquely marked fixture activity. When As A query and paginate activity/log filters, including a guessed B identifier. Then Only authorized A data is returned; counts and pagination do not reveal B content. Verification: TC-096.

## Non-functional acceptance and open targets

These are explicitly proposed acceptance statements. NFR-006 and NFR-007 do not yet have an approved quantitative oracle; executing a diagnostic case does not satisfy those numeric objectives.

### NFR-001 — Security and isolation

Zero unauthorized reads or mutations in the adopted role/project test matrix. Classification: Derived proposed criterion; requires real execution. Related requirements: REQ-003, REQ-004, REQ-005, REQ-017, REQ-019. Status Draft.

### NFR-002 — Source and result truthfulness

Zero invented source facts, approval decisions, execution observations or pass counts in reviewed artifacts. Classification: Recommendation for acceptance. Related requirements: REQ-008, REQ-009, REQ-014, REQ-019, REQ-023, REQ-027. Status Draft.

### NFR-003 — Privacy

Zero raw credentials, recovery codes, provider secrets or source bodies in reviewed usage receipts, public exports and frontend storage. Classification: Derived proposed criterion. Related requirements: REQ-002, REQ-017, REQ-024, REQ-028, REQ-032. Status Draft.

### NFR-004 — Reliability

No duplicate authoritative completion in the prescribed concurrent-claim and retry fixtures; interrupted work remains visibly unresolved. Classification: Recommendation for acceptance. Related requirements: REQ-007, REQ-018, REQ-025, REQ-026. Status Draft.

### NFR-005 — Usability and localization

The prescribed English/Arabic journey works at 375 and 1440 CSS pixels with visible keyboard focus and no inaccessible core action. Classification: Recommended fixture sizes; formal conformance unresolved in GAP-006. Related requirements: REQ-030. Status Draft.

### NFR-006 — Performance and capacity

Measure p50/p95/p99 latency, errors and resource use for a sponsor-approved workload; compare only against approved numeric thresholds. Classification: Gap: target/load/duration pending GAP-003; no performance acceptance executed. Related requirements: REQ-031. Status Draft.

### NFR-007 — Recovery

Restore a consistent sandbox database/object set; record actual recovery time and data cutoff against approved RPO/RTO. Classification: Gap: quantitative RPO/RTO pending GAP-004. Related requirements: REQ-031. Status Draft.

### NFR-008 — Observability

Every prescribed business decision and terminal job/run outcome is reconcilable by project, actor or service identity, operation, reference and time. Classification: Derived proposed criterion. Related requirements: REQ-007, REQ-018, REQ-020, REQ-021, REQ-032. Status Draft.