# Test case catalogue

> 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.

Suite TEST-SUITE-MASTER-001, version 1.0.0. All cases are **manual acceptance designs**, not runnable browser scripts. API/security/worker/provider cases may use approved local harnesses. Actual deployed request schemas, roles, fixtures and oracles must be reviewed first. No test has been approved or run.

## Common execution rules

Use a fresh per-case marker, a disposable approved project, two separate tenant fixtures when required, controlled mail/provider/webhook sinks, and secret-store references. Independent setup is mandatory; never assume a prior case left the correct state. Capture exact builds, UTC times, executor and criterion/case version. Stop dependent actions if setup is missing. A denied or invalid action must preserve unrelated records. Record actual status codes from the approved contract: do not fail a generic denial case solely because a secure 403 is used instead of 404 unless the adopted contract specifies it.

For every case, evidence consists of actual step observations, sanitized UI/API receipts, relevant persisted-state/audit observations and authorized file references. Notification or integration outputs are inspected only where the scenario triggers them; otherwise record Not applicable with a reason. No raw password, recovery code, service key or provider key enters the log. Clean up only records with this case's unique marker; stop temporary workers and pause schedules after testing.

## Detailed cases

### TC-001 — Register and verify a named account

Version 1.0.0 | suite identity | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify register and verify a named account against AC-001-01.

**Trace:** BR-001 → REQ-001 / US-001 → AC-001-01. Source SRC-001.

**Role / target:** account holder; `/en/login`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A unique sample mailbox is controlled by the tester and email delivery uses a test sink.

**Independent data:** Use a fresh TC-001-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A unique sample mailbox is controlled by the tester and email delivery uses a test sink.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A unique sample mailbox is controlled by the tester and email delivery uses a test sink.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Register the mailbox with a 12-character test password, open the delivered verification link, then sign in.

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

3. Sign out and sign in again; the account remains verified. Save a redacted email receipt and account-state observation.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Sign out and sign in again; the account remains verified. Save a redacted email receipt and account-state observation.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-002 — Password and email boundaries reject invalid input

Version 1.0.0 | suite identity | type Boundary | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify password and email boundaries reject invalid input against AC-001-02.

**Trace:** BR-001 → REQ-001 / US-001 → AC-001-02. Source SRC-001.

**Role / target:** account holder; `/en/login`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. No account exists for the test mailbox.

**Independent data:** Use a fresh TC-002-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: No account exists for the test mailbox.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: No account exists for the test mailbox.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Count accounts for the unique fixture via approved administration and confirm no invalid duplicate. Never capture the password.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Invalid attempts show actionable validation and create no usable account; the valid boundary can enter verification.

**Persistence / reconciliation:** Count accounts for the unique fixture via approved administration and confirm no invalid duplicate. Never capture the password.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-003 — Recovery link cannot be replayed

Version 1.0.0 | suite identity | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify recovery link cannot be replayed against AC-001-03.

**Trace:** BR-001 → REQ-001 / US-001 → AC-001-03. Source SRC-001.

**Role / target:** account holder; `/en/login`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A verified sample account and its test inbox exist.

**Independent data:** Use a fresh TC-003-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A verified sample account and its test inbox exist.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A verified sample account and its test inbox exist.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Sign in using the new credential; verify the original credential is rejected and stored evidence contains no recovery token.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The used link cannot reset the password a second time; the first reset remains effective.

**Persistence / reconciliation:** Sign in using the new credential; verify the original credential is rejected and stored evidence contains no recovery token.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-004 — Revoke another active session

Version 1.0.0 | suite identity | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify revoke another active session against AC-002-01.

**Trace:** BR-002 → REQ-002 / US-002 → AC-002-01. Source SRC-002.

**Role / target:** account holder; `/en/account`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Two isolated browser profiles are signed in to the same sample account.

**Independent data:** Use a fresh TC-004-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Two isolated browser profiles are signed in to the same sample account.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Two isolated browser profiles are signed in to the same sample account.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. In profile A revoke profile B from account sessions; in B request protected account and project data.

   Expected: Profile B loses authorized access while A remains usable.

3. Refresh B and replay its previous protected request; access remains denied and no sensitive data is returned.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Profile B loses authorized access while A remains usable.

**Persistence / reconciliation:** Refresh B and replay its previous protected request; access remains denied and no sensitive data is returned.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-005 — Require valid MFA at sign-in

Version 1.0.0 | suite identity | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify require valid mfa at sign-in against AC-002-02.

**Trace:** BR-002 → REQ-002 / US-002 → AC-002-02. Source SRC-002.

**Role / target:** account holder; `/en/account`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. MFA enrollment was completed with a tester-controlled authenticator.

**Independent data:** Use a fresh TC-005-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: MFA enrollment was completed with a tester-controlled authenticator.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: MFA enrollment was completed with a tester-controlled authenticator.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Confirm protected requests before successful MFA expose no project data; screenshots exclude setup secrets and codes.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The incorrect code cannot complete sign-in; the current correct code can.

**Persistence / reconciliation:** Confirm protected requests before successful MFA expose no project data; screenshots exclude setup secrets and codes.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-006 — Recovery code is consumed once

Version 1.0.0 | suite identity | type Recovery | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify recovery code is consumed once against AC-002-03.

**Trace:** BR-002 → REQ-002 / US-002 → AC-002-03. Source SRC-002.

**Role / target:** account holder; `/en/account`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The sample account has MFA and an unused recovery code held outside the pack.

**Independent data:** Use a fresh TC-006-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The sample account has MFA and an unused recovery code held outside the pack.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The sample account has MFA and an unused recovery code held outside the pack.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record redacted authentication outcomes and leave the account with a controlled valid recovery method.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** First use can recover access; second use is rejected.

**Persistence / reconciliation:** Record redacted authentication outcomes and leave the account with a controlled valid recovery method.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-007 — Create an empty project

Version 1.0.0 | suite projects | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify create an empty project against AC-003-01.

**Trace:** BR-003 → REQ-003 / US-003 → AC-003-01. Source SRC-003.

**Role / target:** owner; `/en/projects`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The named owner is signed in and has no project called SAMPLE-A-{runKey}.

**Independent data:** Use a fresh TC-007-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The named owner is signed in and has no project called SAMPLE-A-{runKey}.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The named owner is signed in and has no project called SAMPLE-A-{runKey}.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Create SAMPLE-A-{runKey}, select it, then open its SRS, test library and issues.

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

3. Reload and read the project overview; counts remain zero until an explicit authorized upload or creation.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Reload and read the project overview; counts remain zero until an explicit authorized upload or creation.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-008 — Reject another project identifier

Version 1.0.0 | suite projects | type Tenant isolation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject another project identifier against AC-003-02.

**Trace:** BR-003 → REQ-003 / US-003 → AC-003-02. Source SRC-003.

**Role / target:** owner; `/en/projects`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Owner A belongs only to SAMPLE-A; owner B belongs only to SAMPLE-B containing a marker B-PRIVATE-{runKey}.

**Independent data:** Use a fresh TC-008-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Owner A belongs only to SAMPLE-A; owner B belongs only to SAMPLE-B containing a marker B-PRIVATE-{runKey}.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Owner A belongs only to SAMPLE-A; owner B belongs only to SAMPLE-B containing a marker B-PRIVATE-{runKey}.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. As B confirm the marker and record count are unchanged; retain redacted denial responses.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The server denies access without returning B content and without modifying B.

**Persistence / reconciliation:** As B confirm the marker and record count are unchanged; retain redacted denial responses.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-009 — Switch projects without stale content

Version 1.0.0 | suite projects | type State | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify switch projects without stale content against AC-003-03.

**Trace:** BR-003 → REQ-003 / US-003 → AC-003-03. Source SRC-003.

**Role / target:** owner; `/en/projects`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. One account belongs to A and B, each with a different source-title marker.

**Independent data:** Use a fresh TC-009-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: One account belongs to A and B, each with a different source-title marker.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: One account belongs to A and B, each with a different source-title marker.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Inspect API project context and browser storage; only a non-sensitive project selector may persist locally.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Every displayed source and count belongs to the current authorized project or an explicit unavailable state.

**Persistence / reconciliation:** Inspect API project context and browser storage; only a non-sensitive project selector may persist locally.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-010 — Invite and accept a viewer membership

Version 1.0.0 | suite access | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify invite and accept a viewer membership against AC-004-01.

**Trace:** BR-004 → REQ-004 / US-004 → AC-004-01. Source SRC-004.

**Role / target:** owner; `/en/members`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Owner A controls a fresh project and the invitee has a separate verified account.

**Independent data:** Use a fresh TC-010-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Owner A controls a fresh project and the invitee has a separate verified account.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Owner A controls a fresh project and the invitee has a separate verified account.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Invite the sample mailbox as viewer, accept from that mailbox account, then open the project.

   Expected: The accepted member sees the intended project with viewer capabilities; the owner stays owner.

3. As viewer attempt a requirement mutation; it is denied. Record invitation delivery and membership role without tokens.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The accepted member sees the intended project with viewer capabilities; the owner stays owner.

**Persistence / reconciliation:** As viewer attempt a requirement mutation; it is denied. Record invitation delivery and membership role without tokens.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-011 — Membership removal takes immediate effect

Version 1.0.0 | suite access | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify membership removal takes immediate effect against AC-004-02.

**Trace:** BR-004 → REQ-004 / US-004 → AC-004-02. Source SRC-004.

**Role / target:** owner; `/en/members`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An active tester is signed in and can read SAMPLE-A.

**Independent data:** Use a fresh TC-011-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An active tester is signed in and can read SAMPLE-A.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An active tester is signed in and can read SAMPLE-A.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Refresh and retry an execution action; no command is created.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Removed membership grants no further project access, including with the old browser selector.

**Persistence / reconciliation:** Refresh and retry an execution action; no command is created.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-012 — Protect the last owner

Version 1.0.0 | suite access | type Business rule | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify protect the last owner against AC-004-03.

**Trace:** BR-004 → REQ-004 / US-004 → AC-004-03. Source SRC-004.

**Role / target:** owner; `/en/members`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The project has one active owner and a separate editor.

**Independent data:** Use a fresh TC-012-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The project has one active owner and a separate editor.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The project has one active owner and a separate editor.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Re-read both memberships and verify exactly one transfer result and an attributable activity record.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Removal/demotion cannot leave the project ownerless; a valid transfer makes the new account owner atomically.

**Persistence / reconciliation:** Re-read both memberships and verify exactly one transfer result and an attributable activity record.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-013 — Widget can submit an issue only within scope

Version 1.0.0 | suite access | type Authorization | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify widget can submit an issue only within scope against AC-005-01.

**Trace:** BR-005 → REQ-005 / US-005 → AC-005-01. Source SRC-005.

**Role / target:** widget:write; `/api/project-access-keys`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Owner created a Widget key for A; the key is held in a test secret store.

**Independent data:** Use a fresh TC-013-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Owner created a Widget key for A; the key is held in a test secret store.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Owner created a Widget key for A; the key is held in a test secret store.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

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

   Expected: Issue submission follows the Widget contract; requirement access is rejected.

3. Check the new issue belongs to A and compare the allowed-method policy; never place the raw key in evidence.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Issue submission follows the Widget contract; requirement access is rejected.

**Persistence / reconciliation:** Check the new issue belongs to A and compare the allowed-method policy; never place the raw key in evidence.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-014 — Agent cannot administer project members

Version 1.0.0 | suite access | type Authorization | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify agent cannot administer project members against AC-005-02.

**Trace:** BR-005 → REQ-005 / US-005 → AC-005-02. Source SRC-005.

**Role / target:** agent:execute; `/api/project-access-keys`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A valid A Agent key and a separate owner account exist.

**Independent data:** Use a fresh TC-014-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A valid A Agent key and a separate owner account exist.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A valid A Agent key and a separate owner account exist.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Attempt a member update and owner-only settings change using the Agent key.

   Expected: The server rejects both actions and membership/settings remain unchanged.

3. Read the records as owner and verify zero unauthorized mutations.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The server rejects both actions and membership/settings remain unchanged.

**Persistence / reconciliation:** Read the records as owner and verify zero unauthorized mutations.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-015 — Revoked key fails on its former allowed route

Version 1.0.0 | suite access | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify revoked key fails on its former allowed route against AC-005-03.

**Trace:** BR-005 → REQ-005 / US-005 → AC-005-03. Source SRC-005.

**Role / target:** owner / service agent; `/api/project-access-keys`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An A Widget key has submitted one known fixture issue.

**Independent data:** Use a fresh TC-015-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An A Widget key has submitted one known fixture issue.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An A Widget key has submitted one known fixture issue.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Revoke it as owner and retry a supported issue submission with that key.

   Expected: The revoked key cannot create another issue.

3. Reload the owner key list for masked/revoked display and confirm the duplicate marker is absent.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The revoked key cannot create another issue.

**Persistence / reconciliation:** Reload the owner key list for masked/revoked display and confirm the duplicate marker is absent.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-016 — Upload a labelled BRD source

Version 1.0.0 | suite source-intake | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify upload a labelled brd source against AC-006-01.

**Trace:** BR-006 → REQ-006 / US-006 → AC-006-01. Source SRC-006.

**Role / target:** editor; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A is empty and the tester has reviewed this synthetic BRD and authorized a sandbox import.

**Independent data:** Use a fresh TC-016-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A is empty and the tester has reviewed this synthetic BRD and authorized a sandbox import.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A is empty and the tester has reviewed this synthetic BRD and authorized a sandbox import.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Choose BRD, upload BRD.md through the source intake, and inspect the saved source/job entry.

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

3. Refresh before worker completion; no completed analysis or execution is claimed prematurely.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Refresh before worker completion; no completed analysis or execution is claimed prematurely.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-017 — Reject mismatched content and file type

Version 1.0.0 | suite source-intake | type Validation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject mismatched content and file type against AC-006-02.

**Trace:** BR-006 → REQ-006 / US-006 → AC-006-02. Source SRC-006.

**Role / target:** editor; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A valid tiny Markdown file and a harmless plain-text file renamed as .pdf are available.

**Independent data:** Use a fresh TC-017-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A valid tiny Markdown file and a harmless plain-text file renamed as .pdf are available.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A valid tiny Markdown file and a harmless plain-text file renamed as .pdf are available.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Confirm the rejected file produced no usable analyzed artifact and unrelated documents remain intact.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The mismatch is rejected with a supported actionable error; the valid document enters the normal intake flow.

**Persistence / reconciliation:** Confirm the rejected file produced no usable analyzed artifact and unrelated documents remain intact.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-018 — Enforce the 20 MiB document ceiling

Version 1.0.0 | suite source-intake | type Boundary | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify enforce the 20 mib document ceiling against AC-006-03.

**Trace:** BR-006 → REQ-006 / US-006 → AC-006-03. Source SRC-006.

**Role / target:** editor; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. 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.

**Independent data:** Use a fresh TC-018-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: 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.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: 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.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record byte counts and size-gate responses; do not treat subsequent extraction/provider limitations as a size-gate defect.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The larger file returns the size rejection; the exact-limit file passes the size gate and remains subject to all other validation.

**Persistence / reconciliation:** Record byte counts and size-gate responses; do not treat subsequent extraction/provider limitations as a size-gate defect.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-019 — Observe a queued job through completion

Version 1.0.0 | suite source-intake | type Integration | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify observe a queued job through completion against AC-007-01.

**Trace:** BR-007 → REQ-007 / US-007 → AC-007-01. Source SRC-007.

**Role / target:** editor / operator; `/api/analysis-jobs/[id]`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A small approved synthetic source is queued and the local worker uses a deterministic provider fixture.

**Independent data:** Use a fresh TC-019-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A small approved synthetic source is queued and the local worker uses a deterministic provider fixture.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A small approved synthetic source is queued and the local worker uses a deterministic provider fixture.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Start the bounded worker, refresh the source status, then open the produced artifact.

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

3. Restart the worker after completion; it does not create another artifact for the same completed job.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Restart the worker after completion; it does not create another artifact for the same completed job.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-020 — Recover a transient provider failure

Version 1.0.0 | suite source-intake | type Recovery | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify recover a transient provider failure against AC-007-02.

**Trace:** BR-007 → REQ-007 / US-007 → AC-007-02. Source SRC-007.

**Role / target:** editor / operator; `/api/analysis-jobs/[id]`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A test provider fixture fails once with a retryable error, then returns a valid structured draft.

**Independent data:** Use a fresh TC-020-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A test provider fixture fails once with a retryable error, then returns a valid structured draft.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A test provider fixture fails once with a retryable error, then returns a valid structured draft.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Review error sanitization and links; no provider key, source body or false success appears in usage/error logs.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The job records bounded attempt history; retry preserves source identity and produces at most one successful final artifact version.

**Persistence / reconciliation:** Review error sanitization and links; no provider key, source body or false success appears in usage/error logs.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-021 — Cancel or stop unrecoverable analysis safely

Version 1.0.0 | suite source-intake | type Failure | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify cancel or stop unrecoverable analysis safely against AC-007-03.

**Trace:** BR-007 → REQ-007 / US-007 → AC-007-03. Source SRC-007.

**Role / target:** editor / operator; `/api/analysis-jobs/[id]`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A synthetic malformed provider fixture cannot satisfy the artifact schema.

**Independent data:** Use a fresh TC-021-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A synthetic malformed provider fixture cannot satisfy the artifact schema.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A synthetic malformed provider fixture cannot satisfy the artifact schema.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Confirm unrelated jobs still progress and record the final job ID/status without retrying indefinitely.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Exhaustion/cancellation has a truthful terminal state with an actionable reason; no Approved artifact is synthesized.

**Persistence / reconciliation:** Confirm unrelated jobs still progress and record the final job ID/status without retrying indefinitely.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-022 — Preserve distinct mandatory obligations

Version 1.0.0 | suite requirements | type Business coverage | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify preserve distinct mandatory obligations against AC-008-01.

**Trace:** BR-008 → REQ-008 / US-008 → AC-008-01. Source SRC-008.

**Role / target:** requirements manager; `/api/srs-source-audit`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A short source states two distinct obligations: only owners can invite; removed members lose access.

**Independent data:** Use a fresh TC-022-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A short source states two distinct obligations: only owners can invite; removed members lose access.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A short source states two distinct obligations: only owners can invite; removed members lose access.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Analyze the source using the governed local fixture and inspect the obligation ledger and resulting requirements.

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

3. Reconcile detected/covered/uncovered counts against the two source statements and retain the receipt.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Reconcile detected/covered/uncovered counts against the two source statements and retain the receipt.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-023 — Surface a contradictory source rule

Version 1.0.0 | suite requirements | type Negative | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify surface a contradictory source rule against AC-008-02.

**Trace:** BR-008 → REQ-008 / US-008 → AC-008-02. Source SRC-008.

**Role / target:** requirements manager; `/api/srs-source-audit`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. One synthetic source says viewers may edit and another says viewers are read-only.

**Independent data:** Use a fresh TC-023-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: One synthetic source says viewers may edit and another says viewers are read-only.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: One synthetic source says viewers may edit and another says viewers are read-only.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Try approval while the conflict remains open; readiness must identify the unresolved decision.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** A conflict is visible with both citations and a blocking decision; the output does not silently choose a permission rule.

**Persistence / reconciliation:** Try approval while the conflict remains open; readiness must identify the unresolved decision.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-024 — Invalidate a stale coverage receipt

Version 1.0.0 | suite requirements | type Versioning | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify invalidate a stale coverage receipt against AC-008-03.

**Trace:** BR-008 → REQ-008 / US-008 → AC-008-03. Source SRC-008.

**Role / target:** requirements manager; `/api/srs-source-audit`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A source has a complete draft coverage receipt.

**Independent data:** Use a fresh TC-024-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A source has a complete draft coverage receipt.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A source has a complete draft coverage receipt.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Compare version/hash/ledger counts and confirm prior immutable evidence remains distinguishable.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The old receipt cannot establish complete coverage for the new hash; the new obligation is covered or explicitly listed as a gap.

**Persistence / reconciliation:** Compare version/hash/ledger counts and confirm prior immutable evidence remains distinguishable.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-025 — Generate a complete reviewable story

Version 1.0.0 | suite requirements | type Content quality | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify generate a complete reviewable story against AC-009-01.

**Trace:** BR-009 → REQ-009 / US-009 → AC-009-01. Source SRC-009.

**Role / target:** business analyst; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An approved-to-analyze synthetic BRD contains project invitation scope, actors and expected business result.

**Independent data:** Use a fresh TC-025-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An approved-to-analyze synthetic BRD contains project invitation scope, actors and expected business result.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An approved-to-analyze synthetic BRD contains project invitation scope, actors and expected business result.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request BRD-to-SRS and inspect the invitation story against the stage contract.

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

3. Check each distinct obligation has a requirement link and every professional addition is labelled derived or recommendation.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Check each distinct obligation has a requirement link and every professional addition is labelled derived or recommendation.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-026 — Missing business threshold becomes a question

Version 1.0.0 | suite requirements | type Ambiguity | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify missing business threshold becomes a question against AC-009-02.

**Trace:** BR-009 → REQ-009 / US-009 → AC-009-02. Source SRC-009.

**Role / target:** business analyst; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The source says the system must be fast but supplies no latency target.

**Independent data:** Use a fresh TC-026-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The source says the system must be fast but supplies no latency target.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The source says the system must be fast but supplies no latency target.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Confirm the artifact remains unapproved and the missing threshold is traceable to its vague source statement.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** No invented latency target is presented as sourced; a decision question or explicitly proposed measurable target is returned.

**Persistence / reconciliation:** Confirm the artifact remains unapproved and the missing threshold is traceable to its vague source statement.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-027 — Review only the requested source section

Version 1.0.0 | suite requirements | type Scope | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify review only the requested source section against AC-009-03.

**Trace:** BR-009 → REQ-009 / US-009 → AC-009-03. Source SRC-009.

**Role / target:** business analyst; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Only chapter 2 is supplied to a bounded section analysis fixture.

**Independent data:** Use a fresh TC-027-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Only chapter 2 is supplied to a bounded section analysis fixture.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Only chapter 2 is supplied to a bounded section analysis fixture.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Verify source locators fall inside the supplied section and any overall completeness statement is deferred.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The bounded result does not claim unseen chapters are absent; it records only uncertainties evidenced in chapter 2.

**Persistence / reconciliation:** Verify source locators fall inside the supplied section and any overall completeness statement is deferred.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-028 — Approve a reviewed requirement with no blockers

Version 1.0.0 | suite requirements | type Workflow | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify approve a reviewed requirement with no blockers against AC-010-01.

**Trace:** BR-010 → REQ-010 / US-010 → AC-010-01. Source SRC-010.

**Role / target:** requirements manager; `/api/requirements-management`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A draft requirement has complete sources, no open blocking findings and an authorized reviewer under the current decision policy.

**Independent data:** Use a fresh TC-028-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A draft requirement has complete sources, no open blocking findings and an authorized reviewer under the current decision policy.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A draft requirement has complete sources, no open blocking findings and an authorized reviewer under the current decision policy.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Submit for review, inspect gates, then approve with an attributable rationale.

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

3. Refresh history and verify the approved content matches the reviewed version and explicit decision.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Refresh history and verify the approved content matches the reviewed version and explicit decision.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-029 — Block approval with unresolved findings

Version 1.0.0 | suite requirements | type Business rule | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify block approval with unresolved findings against AC-010-02.

**Trace:** BR-010 → REQ-010 / US-010 → AC-010-02. Source SRC-010.

**Role / target:** requirements manager; `/api/requirements-management`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A requirement has an open finding that blocks Approval.

**Independent data:** Use a fresh TC-029-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A requirement has an open finding that blocks Approval.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A requirement has an open finding that blocks Approval.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Submit or attempt the approval action using an authorized manager.

   Expected: The gate identifies the blocking finding and does not mark the requirement Approved.

3. Read status/history and verify no hidden approval or executable downstream eligibility was created.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The gate identifies the blocking finding and does not mark the requirement Approved.

**Persistence / reconciliation:** Read status/history and verify no hidden approval or executable downstream eligibility was created.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-030 — Reject stale concurrent edits

Version 1.0.0 | suite requirements | type Concurrency | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject stale concurrent edits against AC-010-03.

**Trace:** BR-010 → REQ-010 / US-010 → AC-010-03. Source SRC-010.

**Role / target:** requirements manager; `/api/requirements-management`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Two tabs load the same requirement management version.

**Independent data:** Use a fresh TC-030-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Two tabs load the same requirement management version.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Two tabs load the same requirement management version.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Compare revision history and current content; affected tests are invalidated when the changed requirement makes their approval stale.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The stale operation is rejected or requires reload; it cannot overwrite A silently.

**Persistence / reconciliation:** Compare revision history and current content; affected tests are invalidated when the changed requirement makes their approval stale.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-031 — Read a hierarchy and story detail

Version 1.0.0 | suite requirements | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify read a hierarchy and story detail against AC-011-01.

**Trace:** BR-011 → REQ-011 / US-011 → AC-011-01. Source SRC-011.

**Role / target:** viewer; `/en/srs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has a reviewed fixture module, workflow and story with known source markers.

**Independent data:** Use a fresh TC-031-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has a reviewed fixture module, workflow and story with known source markers.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has a reviewed fixture module, workflow and story with known source markers.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Navigate from the SRS directory to workflow and story, then back to the project view.

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

3. Reload a direct story URL and confirm it resolves only while membership/project context is valid.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Names, parents, criteria and source links describe the same project-owned story throughout.

**Persistence / reconciliation:** Reload a direct story URL and confirm it resolves only while membership/project context is valid.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-032 — Keep an unmapped requirement visible

Version 1.0.0 | suite requirements | type Coverage | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify keep an unmapped requirement visible against AC-011-02.

**Trace:** BR-011 → REQ-011 / US-011 → AC-011-02. Source SRC-011.

**Role / target:** viewer; `/en/srs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A requirement exists with no confirmed workflow or route.

**Independent data:** Use a fresh TC-032-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A requirement exists with no confirmed workflow or route.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A requirement exists with no confirmed workflow or route.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Open traceability/coverage and filter for the unmapped record.

   Expected: The record stays visibly unmapped and is not counted as fully route-covered.

3. Add a confirmed explicit link using an authorized editor, then verify only that mapping changes.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The record stays visibly unmapped and is not counted as fully route-covered.

**Persistence / reconciliation:** Add a confirmed explicit link using an authorized editor, then verify only that mapping changes.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-033 — Reject a cross-project traceability edge

Version 1.0.0 | suite requirements | type Tenant isolation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject a cross-project traceability edge against AC-011-03.

**Trace:** BR-011 → REQ-011 / US-011 → AC-011-03. Source SRC-011.

**Role / target:** editor; `/en/srs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A and B each contain a distinct story; the actor can edit only A.

**Independent data:** Use a fresh TC-033-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A and B each contain a distinct story; the actor can edit only A.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A and B each contain a distinct story; the actor can edit only A.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Read A traceability after refresh and confirm no B ID/title entered its graph.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The server rejects or omits the unauthorized edge and returns no B content.

**Persistence / reconciliation:** Read A traceability after refresh and confirm no B ID/title entered its graph.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-034 — Edit a story and inspect its history

Version 1.0.0 | suite requirements | type Versioning | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify edit a story and inspect its history against AC-012-01.

**Trace:** BR-012 → REQ-012 / US-012 → AC-012-01. Source SRC-012.

**Role / target:** editor; `/api/story-edits`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A contains a story with a stable identifier and a known acceptance criterion.

**Independent data:** Use a fresh TC-034-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A contains a story with a stable identifier and a known acceptance criterion.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A contains a story with a stable identifier and a known acceptance criterion.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Change its business rule with a reason and inspect the history and impact views.

   Expected: The new text is attributable to the editor and previous content remains identifiable.

3. Check linked tests/coverage reflect the changed version and no other project story changes.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The new text is attributable to the editor and previous content remains identifiable.

**Persistence / reconciliation:** Check linked tests/coverage reflect the changed version and no other project story changes.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-035 — Translate Arabic without losing obligations

Version 1.0.0 | suite requirements | type Localization | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify translate arabic without losing obligations against AC-012-02.

**Trace:** BR-012 → REQ-012 / US-012 → AC-012-02. Source SRC-012.

**Role / target:** editor; `/api/story-edits`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The story contains Arabic text, a stable ID and a numeric limit; a local translation fixture is configured.

**Independent data:** Use a fresh TC-035-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The story contains Arabic text, a stable ID and a numeric limit; a local translation fixture is configured.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The story contains Arabic text, a stable ID and a numeric limit; a local translation fixture is configured.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Inspect any uncertain term as a gap; translation alone never constitutes approval.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** IDs, role restrictions, negation and numeric values are preserved; translation is a reviewable artifact.

**Persistence / reconciliation:** Inspect any uncertain term as a gap; translation alone never constitutes approval.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-036 — Preserve the story after provider failure

Version 1.0.0 | suite requirements | type Failure | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify preserve the story after provider failure against AC-012-03.

**Trace:** BR-012 → REQ-012 / US-012 → AC-012-03. Source SRC-012.

**Role / target:** editor; `/api/story-edits`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The original bilingual story is persisted and the translation provider fixture returns an error.

**Independent data:** Use a fresh TC-036-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The original bilingual story is persisted and the translation provider fixture returns an error.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The original bilingual story is persisted and the translation provider fixture returns an error.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request translation and observe the failure; reload the story.

   Expected: The UI/API report failure and the original story is intact.

3. Confirm no empty/partial translation silently replaced accepted content and retries retain the intended source version.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The UI/API report failure and the original story is intact.

**Persistence / reconciliation:** Confirm no empty/partial translation silently replaced accepted content and retries retain the intended source version.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-037 — Import cases with their original IDs

Version 1.0.0 | suite test-design | type Import | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify import cases with their original ids against AC-013-01.

**Trace:** BR-013 → REQ-013 / US-013 → AC-013-01. Source SRC-013.

**Role / target:** tester; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A CSV fixture contains two distinct original IDs, steps, expected results and source requirement IDs.

**Independent data:** Use a fresh TC-037-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A CSV fixture contains two distinct original IDs, steps, expected results and source requirement IDs.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A CSV fixture contains two distinct original IDs, steps, expected results and source requirement IDs.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Upload as test-cases and inspect the normalized suite.

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

3. Compare original and normalized counts/text; no execution result is inferred from the import.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Both case identities and detailed steps survive normalization with source lineage and Draft review state.

**Persistence / reconciliation:** Compare original and normalized counts/text; no execution result is inferred from the import.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-038 — Detect duplicate and unmapped cases

Version 1.0.0 | suite test-design | type Quality | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify detect duplicate and unmapped cases against AC-013-02.

**Trace:** BR-013 → REQ-013 / US-013 → AC-013-02. Source SRC-013.

**Role / target:** tester; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A CSV contains one exact duplicate and a case referencing an unknown requirement.

**Independent data:** Use a fresh TC-038-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A CSV contains one exact duplicate and a case referencing an unknown requirement.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A CSV contains one exact duplicate and a case referencing an unknown requirement.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Import the file and inspect review findings and mapping.

   Expected: The duplicate and unknown link are visible for review; neither silently inflates verified coverage.

3. Resolve mapping only with source evidence and retain original case identity in the review record.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The duplicate and unknown link are visible for review; neither silently inflates verified coverage.

**Persistence / reconciliation:** Resolve mapping only with source evidence and retain original case identity in the review record.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-039 — Reject execution readiness for incomplete cases

Version 1.0.0 | suite test-design | type Negative | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject execution readiness for incomplete cases against AC-013-03.

**Trace:** BR-013 → REQ-013 / US-013 → AC-013-03. Source SRC-013.

**Role / target:** tester; `/api/project-documents`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An imported case has a title but no expected result or usable steps.

**Independent data:** Use a fresh TC-039-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An imported case has a title but no expected result or usable steps.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An imported case has a title but no expected result or usable steps.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Inspect its readiness and attempt to include it in an execution preview.

   Expected: The case remains non-executable with actionable missing-field reasons.

3. Confirm no browser command or passing run is created by the attempted preview.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The case remains non-executable with actionable missing-field reasons.

**Persistence / reconciliation:** Confirm no browser command or passing run is created by the attempted preview.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-040 — Design cases for an approved business story

Version 1.0.0 | suite test-design | type Quality | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify design cases for an approved business story against AC-014-01.

**Trace:** BR-014 → REQ-014 / US-014 → AC-014-01. Source SRC-014.

**Role / target:** tester; `/api/story-test-generation`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A review-approved invitation requirement has positive and permission criteria; a local structured provider fixture is configured.

**Independent data:** Use a fresh TC-040-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A review-approved invitation requirement has positive and permission criteria; a local structured provider fixture is configured.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A review-approved invitation requirement has positive and permission criteria; a local structured provider fixture is configured.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request test design and inspect each returned case and its exact criterion links.

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

3. Open execution results and verify no run, pass or screenshot was invented during generation.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Open execution results and verify no run, pass or screenshot was invented during generation.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-041 — Generate missing coverage without replacing existing work

Version 1.0.0 | suite test-design | type Delta | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify generate missing coverage without replacing existing work against AC-014-02.

**Trace:** BR-014 → REQ-014 / US-014 → AC-014-02. Source SRC-014.

**Role / target:** tester; `/api/story-test-generation`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The suite already has a reviewed happy-path case but lacks the revoked-member criterion.

**Independent data:** Use a fresh TC-041-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The suite already has a reviewed happy-path case but lacks the revoked-member criterion.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The suite already has a reviewed happy-path case but lacks the revoked-member criterion.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Check case IDs and duplicates; review status for newly generated work remains Draft.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The new case addresses the missing criterion and preserves the existing reviewed case/version.

**Persistence / reconciliation:** Check case IDs and duplicates; review status for newly generated work remains Draft.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-042 — Reject unsupported test references from a provider

Version 1.0.0 | suite test-design | type Validation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject unsupported test references from a provider against AC-014-03.

**Trace:** BR-014 → REQ-014 / US-014 → AC-014-03. Source SRC-014.

**Role / target:** tester; `/api/story-test-generation`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A provider fixture returns a case referencing a nonexistent requirement or criterion.

**Independent data:** Use a fresh TC-042-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A provider fixture returns a case referencing a nonexistent requirement or criterion.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A provider fixture returns a case referencing a nonexistent requirement or criterion.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Run generation through the backend validator.

   Expected: Invalid links cannot enter approved coverage; the job reports a validation gap or bounded correction.

3. Check the persisted suite and coverage for orphan references; invalid provider output produces no ready command.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Invalid links cannot enter approved coverage; the job reports a validation gap or bounded correction.

**Persistence / reconciliation:** Check the persisted suite and coverage for orphan references; invalid provider output produces no ready command.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-043 — Filter and select the intended test scope

Version 1.0.0 | suite test-design | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify filter and select the intended test scope against AC-015-01.

**Trace:** BR-015 → REQ-015 / US-015 → AC-015-01. Source SRC-015.

**Role / target:** tester; `/api/test-case-groups`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has distinguishable module suites with different priorities and review states.

**Independent data:** Use a fresh TC-043-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has distinguishable module suites with different priorities and review states.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has distinguishable module suites with different priorities and review states.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Apply a module and priority filter, select the visible scope, then inspect selected IDs/counts.

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

3. Reload and compare server-resolved selection with visible filters; no B cases are present.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Selection contains only matching project cases; hidden stale selections are not silently included.

**Persistence / reconciliation:** Reload and compare server-resolved selection with visible filters; no B cases are present.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-044 — Explain mixed executable and blocked selection

Version 1.0.0 | suite test-design | type Readiness | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify explain mixed executable and blocked selection against AC-015-02.

**Trace:** BR-015 → REQ-015 / US-015 → AC-015-02. Source SRC-015.

**Role / target:** tester; `/api/test-case-groups`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The selection contains one approved browser case, one Draft case and one manual-only case.

**Independent data:** Use a fresh TC-044-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The selection contains one approved browser case, one Draft case and one manual-only case.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The selection contains one approved browser case, one Draft case and one manual-only case.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Verify no command is queued; if opting into ready-only later, the omitted cases are disclosed.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The preview returns an explicit mixed-selection blocker with ready/blocked/manual counts.

**Persistence / reconciliation:** Verify no command is queued; if opting into ready-only later, the omitted cases are disclosed.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-045 — Version change removes stale readiness

Version 1.0.0 | suite test-design | type Versioning | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify version change removes stale readiness against AC-015-03.

**Trace:** BR-015 → REQ-015 / US-015 → AC-015-03. Source SRC-015.

**Role / target:** tester; `/api/test-case-groups`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A case was approved against requirement version 1.

**Independent data:** Use a fresh TC-045-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A case was approved against requirement version 1.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A case was approved against requirement version 1.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Inspect the displayed reason, affected version link and queued-command count.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The selection cannot treat the stale approval as current execution readiness.

**Persistence / reconciliation:** Inspect the displayed reason, affected version link and queued-command count.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-046 — Confirm a current safe execution preview

Version 1.0.0 | suite execution | type Workflow | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify confirm a current safe execution preview against AC-016-01.

**Trace:** BR-016 → REQ-016 / US-016 → AC-016-01. Source SRC-016.

**Role / target:** tester; `/api/execution-previews`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has one approved browser-ready case, a configured sandbox target and an authorized tester.

**Independent data:** Use a fresh TC-046-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has one approved browser-ready case, a configured sandbox target and an authorized tester.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has one approved browser-ready case, a configured sandbox target and an authorized tester.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Preview the case, review the target/role/counts, then confirm using the returned preview contract.

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

3. Read the command as owner and compare selected IDs, role, environment and preview metadata.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Read the command as owner and compare selected IDs, role, environment and preview metadata.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-047 — Reject confirmation after target change

Version 1.0.0 | suite execution | type Safety | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject confirmation after target change against AC-016-02.

**Trace:** BR-016 → REQ-016 / US-016 → AC-016-02. Source SRC-016.

**Role / target:** tester; `/api/execution-previews`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A valid preview exists but has not been confirmed.

**Independent data:** Use a fresh TC-047-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A valid preview exists but has not been confirmed.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A valid preview exists but has not been confirmed.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Verify command count did not increase and the new preview displays the changed target.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The stale preview cannot queue execution against the changed target; a fresh preview is required.

**Persistence / reconciliation:** Verify command count did not increase and the new preview displays the changed target.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-048 — Reject confirmation after membership or case change

Version 1.0.0 | suite execution | type Concurrency | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject confirmation after membership or case change against AC-016-03.

**Trace:** BR-016 → REQ-016 / US-016 → AC-016-03. Source SRC-016.

**Role / target:** tester; `/api/execution-previews`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A tester holds a preview for case version 1.

**Independent data:** Use a fresh TC-048-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A tester holds a preview for case version 1.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A tester holds a preview for case version 1.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Read persisted commands as owner and verify no unauthorized or stale command was created.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Current authorization and version checks reject the stale confirmation.

**Persistence / reconciliation:** Read persisted commands as owner and verify no unauthorized or stale command was created.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-049 — Store a sample credential without exposing its secret

Version 1.0.0 | suite execution | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify store a sample credential without exposing its secret against AC-017-01.

**Trace:** BR-017 → REQ-017 / US-017 → AC-017-01. Source SRC-017.

**Role / target:** owner / service agent; `/api/project-credentials/[id]/lease`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Owner has a tester-controlled sandbox account; only the secret store contains its password.

**Independent data:** Use a fresh TC-049-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Owner has a tester-controlled sandbox account; only the secret store contains its password.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Owner has a tester-controlled sandbox account; only the secret store contains its password.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

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

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

3. Inspect redacted network responses and logs; no plaintext credential appears outside the intended protected transit/lease flow.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The credential is selectable by reference and list/UI/storage do not expose the password.

**Persistence / reconciliation:** Inspect redacted network responses and logs; no plaintext credential appears outside the intended protected transit/lease flow.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-050 — Reject a lease from a viewer or Widget key

Version 1.0.0 | suite execution | type Authorization | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject a lease from a viewer or widget key against AC-017-02.

**Trace:** BR-017 → REQ-017 / US-017 → AC-017-02. Source SRC-017.

**Role / target:** owner / service agent; `/api/project-credentials/[id]/lease`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A ready A credential exists; viewer and Widget identities have no Agent scope.

**Independent data:** Use a fresh TC-050-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A ready A credential exists; viewer and Widget identities have no Agent scope.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A ready A credential exists; viewer and Widget identities have no Agent scope.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request its lease using each disallowed identity.

   Expected: Both requests are denied without credential material.

3. Confirm credential state is unchanged and evidence captures only status/error, never secrets.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Both requests are denied without credential material.

**Persistence / reconciliation:** Confirm credential state is unchanged and evidence captures only status/error, never secrets.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-051 — Reject a foreign or revoked credential lease

Version 1.0.0 | suite execution | type Tenant isolation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject a foreign or revoked credential lease against AC-017-03.

**Trace:** BR-017 → REQ-017 / US-017 → AC-017-03. Source SRC-017.

**Role / target:** agent:execute; `/api/project-credentials/[id]/lease`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The Agent belongs to A and a distinct B credential identifier is known in the isolated fixture.

**Independent data:** Use a fresh TC-051-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The Agent belongs to A and a distinct B credential identifier is known in the isolated fixture.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The Agent belongs to A and a distinct B credential identifier is known in the isolated fixture.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request B credential with A Agent, then revoke an A credential and request that lease.

   Expected: Neither foreign nor revoked credential can be leased.

3. Read credential metadata as the respective owners and record denial outcomes with credential values redacted.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Neither foreign nor revoked credential can be leased.

**Persistence / reconciliation:** Read credential metadata as the respective owners and record denial outcomes with credential values redacted.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-052 — Claim and complete a safe sandbox command

Version 1.0.0 | suite execution | type Execution | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify claim and complete a safe sandbox command against AC-018-01.

**Trace:** BR-018 → REQ-018 / US-018 → AC-018-01. Source SRC-018.

**Role / target:** agent:execute; `/api/test-commands`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An authorized command contains one approved read-only browser case and an Agent key for A.

**Independent data:** Use a fresh TC-052-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An authorized command contains one approved read-only browser case and an Agent key for A.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An authorized command contains one approved read-only browser case and an Agent key for A.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

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

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

3. Refresh operator views; case version, target and agent identity match the command and result.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The command moves through truthful progress to its computed terminal state and is linked to its real run.

**Persistence / reconciliation:** Refresh operator views; case version, target and agent identity match the command and result.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-053 — Prevent competing agents from duplicating a claim

Version 1.0.0 | suite execution | type Concurrency | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify prevent competing agents from duplicating a claim against AC-018-02.

**Trace:** BR-018 → REQ-018 / US-018 → AC-018-02. Source SRC-018.

**Role / target:** agent:execute; `/api/test-commands`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. One unclaimed command and two isolated authorized Agent clients exist.

**Independent data:** Use a fresh TC-053-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: One unclaimed command and two isolated authorized Agent clients exist.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: One unclaimed command and two isolated authorized Agent clients exist.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record claim responses and persisted command/run counts; stop any losing client before it touches the target.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Only a valid current claimant may perform/complete the command; no duplicate authoritative run is accepted.

**Persistence / reconciliation:** Record claim responses and persisted command/run counts; stop any losing client before it touches the target.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-054 — Recover from agent interruption honestly

Version 1.0.0 | suite execution | type Recovery | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify recover from agent interruption honestly against AC-018-03.

**Trace:** BR-018 → REQ-018 / US-018 → AC-018-03. Source SRC-018.

**Role / target:** agent:execute; `/api/test-commands`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An Agent has claimed a safe read-only command; the recovery timing policy is recorded.

**Independent data:** Use a fresh TC-054-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An Agent has claimed a safe read-only command; the recovery timing policy is recorded.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An Agent has claimed a safe read-only command; the recovery timing policy is recorded.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Check stale submissions cannot overwrite a newer accepted result and record final blocked/recovered state accurately.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Progress remains distinguishable from success; recovery cannot manufacture missing step evidence.

**Persistence / reconciliation:** Check stale submissions cannot overwrite a newer accepted result and record final blocked/recovered state accurately.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-055 — Submit an objectively verifiable passing observation

Version 1.0.0 | suite evidence | type Evidence | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify submit an objectively verifiable passing observation against AC-019-01.

**Trace:** BR-019 → REQ-019 / US-019 → AC-019-01. Source SRC-019.

**Role / target:** agent:execute / tester; `/api/test-runs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An approved safe test expects a specific page text and URL on the sandbox build.

**Independent data:** Use a fresh TC-055-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An approved safe test expects a specific page text and URL on the sandbox build.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An approved safe test expects a specific page text and URL on the sandbox build.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Execute it and submit actual step receipts plus matching objective assertions and allowed evidence.

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

3. Open the evidence as an authorized member and verify contents/time/target correspond to the run.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The recorded outcome is computed from the actual observations and links to the exact case/build.

**Persistence / reconciliation:** Open the evidence as an authorized member and verify contents/time/target correspond to the run.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-056 — Reject a reported pass contradicted by actual data

Version 1.0.0 | suite evidence | type Negative | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject a reported pass contradicted by actual data against AC-019-02.

**Trace:** BR-019 → REQ-019 / US-019 → AC-019-02. Source SRC-019.

**Role / target:** agent:execute / tester; `/api/test-runs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The assertion contract expects HTTP status 200; a controlled target returns 500.

**Independent data:** Use a fresh TC-056-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The assertion contract expects HTTP status 200; a controlled target returns 500.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The assertion contract expects HTTP status 200; a controlled target returns 500.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Verify dashboards and coverage do not count this as passed and retain the 500 observation as evidence.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The backend does not record an authoritative pass; computed outcome or validation identifies the mismatch.

**Persistence / reconciliation:** Verify dashboards and coverage do not count this as passed and retain the 500 observation as evidence.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-057 — Deny expired, tampered or cross-project evidence access

Version 1.0.0 | suite evidence | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify deny expired, tampered or cross-project evidence access against AC-019-03.

**Trace:** BR-019 → REQ-019 / US-019 → AC-019-03. Source SRC-019.

**Role / target:** agent:execute / tester; `/api/test-runs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A private evidence file exists and the configured signed-URL expiry is recorded.

**Independent data:** Use a fresh TC-057-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A private evidence file exists and the configured signed-URL expiry is recorded.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A private evidence file exists and the configured signed-URL expiry is recorded.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Obtain a new authorized link where supported and verify valid access still retrieves the correct file.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Access is denied without exposing object credentials or a reusable private storage location.

**Persistence / reconciliation:** Obtain a new authorized link where supported and verify valid access still retrieves the correct file.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-058 — Capture a reproducible synthetic defect

Version 1.0.0 | suite defects | type Workflow | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify capture a reproducible synthetic defect against AC-020-01.

**Trace:** BR-020 → REQ-020 / US-020 → AC-020-01. Source SRC-020.

**Role / target:** tester / editor; `/api/issues`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A controlled sandbox page displays a wrong label; the expected label is linked to a reviewed criterion.

**Independent data:** Use a fresh TC-058-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A controlled sandbox page displays a wrong label; the expected label is linked to a reviewed criterion.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A controlled sandbox page displays a wrong label; the expected label is linked to a reviewed criterion.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Create an issue with reproduction steps, actual/expected text, target build and redacted screenshot.

   Expected: The issue retains the supplied facts and links without asserting unobserved impact.

3. Reload issue details and verify attachment scope, report author, time and criterion/run references.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The issue retains the supplied facts and links without asserting unobserved impact.

**Persistence / reconciliation:** Reload issue details and verify attachment scope, report author, time and criterion/run references.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-059 — Approve or reject with a recorded reason

Version 1.0.0 | suite defects | type Review | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify approve or reject with a recorded reason against AC-020-02.

**Trace:** BR-020 → REQ-020 / US-020 → AC-020-02. Source SRC-020.

**Role / target:** tester / editor; `/api/issues`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Two fixture issues exist: one reproducible and one contradicted by the approved requirement.

**Independent data:** Use a fresh TC-059-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Two fixture issues exist: one reproducible and one contradicted by the approved requirement.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Two fixture issues exist: one reproducible and one contradicted by the approved requirement.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Read history and verify the rejected report did not become an executable fix obligation automatically.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Each decision follows an allowed transition with an attributable business reason.

**Persistence / reconciliation:** Read history and verify the rejected report did not become an executable fix obligation automatically.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-060 — Prevent unauthorized issue closure

Version 1.0.0 | suite defects | type Authorization | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify prevent unauthorized issue closure against AC-020-03.

**Trace:** BR-020 → REQ-020 / US-020 → AC-020-03. Source SRC-020.

**Role / target:** tester / editor; `/api/issues`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An issue is open and a viewer or Widget key can identify it within the fixture.

**Independent data:** Use a fresh TC-060-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An issue is open and a viewer or Widget key can identify it within the fixture.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An issue is open and a viewer or Widget key can identify it within the fixture.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Attempt to change it directly to Closed using the disallowed identity.

   Expected: The transition is rejected and the original status remains.

3. Reload as owner and confirm no closure/retest evidence was fabricated.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The transition is rejected and the original status remains.

**Persistence / reconciliation:** Reload as owner and confirm no closure/retest evidence was fabricated.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-061 — Move a delivered fix to awaiting retest

Version 1.0.0 | suite defects | type Workflow | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify move a delivered fix to awaiting retest against AC-021-01.

**Trace:** BR-021 → REQ-021 / US-021 → AC-021-01. Source SRC-020.

**Role / target:** editor / tester; `/api/issues/[id]`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A confirmed issue is approved for fix and a real sandbox fix build is available.

**Independent data:** Use a fresh TC-061-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A confirmed issue is approved for fix and a real sandbox fix build is available.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A confirmed issue is approved for fix and a real sandbox fix build is available.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Record the exact build and delivery reference using the supported fix transition.

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

3. Read issue history and make the same build available to the retest runner.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Read issue history and make the same build available to the retest runner.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-062 — Reject closure using a different build or unrelated case

Version 1.0.0 | suite defects | type Business rule | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject closure using a different build or unrelated case against AC-021-02.

**Trace:** BR-021 → REQ-021 / US-021 → AC-021-02. Source SRC-020.

**Role / target:** editor / tester; `/api/issues/[id]`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The issue awaits retest on build A; a passing fixture run exists on build B or unrelated case lineage.

**Independent data:** Use a fresh TC-062-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The issue awaits retest on build A; a passing fixture run exists on build B or unrelated case lineage.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The issue awaits retest on build A; a passing fixture run exists on build B or unrelated case lineage.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Attempt closure using the unrelated or wrong-build run.

   Expected: The gate rejects closure and explains the mismatched evidence.

3. Verify the issue still awaits valid retest and no release readiness metric treats it as closed.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The gate rejects closure and explains the mismatched evidence.

**Persistence / reconciliation:** Verify the issue still awaits valid retest and no release readiness metric treats it as closed.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-063 — Close only after a real matching retest

Version 1.0.0 | suite defects | type Retest | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify close only after a real matching retest against AC-021-03.

**Trace:** BR-021 → REQ-021 / US-021 → AC-021-03. Source SRC-020.

**Role / target:** editor / tester; `/api/issues/[id]`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The actual fix build is deployed in the isolated target and a linked approved case is ready.

**Independent data:** Use a fresh TC-063-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The actual fix build is deployed in the isolated target and a linked approved case is ready.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The actual fix build is deployed in the isolated target and a linked approved case is ready.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record closure actor/time and links; if any assertion fails, keep the issue open/reopened instead of forcing closure.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Closure succeeds only if the required run is fully passing and evidence/lineage/build match.

**Persistence / reconciliation:** Record closure actor/time and links; if any assertion fails, keep the issue open/reopened instead of forcing closure.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-064 — Trace a requirement change to its tests

Version 1.0.0 | suite impact | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify trace a requirement change to its tests against AC-022-01.

**Trace:** BR-022 → REQ-022 / US-022 → AC-022-01. Source SRC-021.

**Role / target:** editor; `/api/project-impact`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A requirement links to two cases and an unrelated requirement links to a third.

**Independent data:** Use a fresh TC-064-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A requirement links to two cases and an unrelated requirement links to a third.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A requirement links to two cases and an unrelated requirement links to a third.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Change the first requirement meaningfully and inspect impact.

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

3. Review proposed regression IDs against the link graph and record the selected scope.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Review proposed regression IDs against the link graph and record the selected scope.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-065 — Show uncertainty when mapping is incomplete

Version 1.0.0 | suite impact | type Negative | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify show uncertainty when mapping is incomplete against AC-022-02.

**Trace:** BR-022 → REQ-022 / US-022 → AC-022-02. Source SRC-021.

**Role / target:** editor; `/api/project-impact`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A changed requirement lacks route or case links.

**Independent data:** Use a fresh TC-065-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A changed requirement lacks route or case links.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A changed requirement lacks route or case links.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request impact and inspect coverage/gaps.

   Expected: The response identifies missing mappings and cannot claim no impact merely because no link exists.

3. Keep regression readiness pending until the owner reviews the missing mapping.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The response identifies missing mappings and cannot claim no impact merely because no link exists.

**Persistence / reconciliation:** Keep regression readiness pending until the owner reviews the missing mapping.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-066 — Ground an impact answer in the selected project

Version 1.0.0 | suite impact | type AI grounding | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify ground an impact answer in the selected project against AC-022-03.

**Trace:** BR-022 → REQ-022 / US-022 → AC-022-03. Source SRC-021.

**Role / target:** editor; `/api/project-impact`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A and B contain different similarly named requirements; A has only one accessible source.

**Independent data:** Use a fresh TC-066-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A and B contain different similarly named requirements; A has only one accessible source.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A and B contain different similarly named requirements; A has only one accessible source.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Check no B details, fabricated IDs or unsupported implementation promises appear.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Citations resolve to A records; unsupported consequences are marked uncertain.

**Persistence / reconciliation:** Check no B details, fabricated IDs or unsupported implementation promises appear.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-067 — Distinguish designed from executed coverage

Version 1.0.0 | suite validation | type Reporting | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify distinguish designed from executed coverage against AC-023-01.

**Trace:** BR-023 → REQ-023 / US-023 → AC-023-01. Source SRC-022.

**Role / target:** owner; `/api/lifecycle`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has four in-scope criteria, two linked Draft cases and no runs.

**Independent data:** Use a fresh TC-067-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has four in-scope criteria, two linked Draft cases and no runs.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has four in-scope criteria, two linked Draft cases and no runs.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Open traceability and release/coverage views.

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

3. Check approved coverage is also zero and the UI does not display a fabricated execution percentage.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Designed criterion coverage is 2/4 where explicit links exist; executed/passed coverage remains zero.

**Persistence / reconciliation:** Check approved coverage is also zero and the UI does not display a fabricated execution percentage.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-068 — Keep a critical security gap as a release blocker

Version 1.0.0 | suite validation | type Business rule | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify keep a critical security gap as a release blocker against AC-023-02.

**Trace:** BR-023 → REQ-023 / US-023 → AC-023-02. Source SRC-022.

**Role / target:** owner; `/api/lifecycle`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. Most cases have valid passing evidence but a critical tenant-isolation criterion has no accepted run.

**Independent data:** Use a fresh TC-068-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: Most cases have valid passing evidence but a critical tenant-isolation criterion has no accepted run.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: Most cases have valid passing evidence but a critical tenant-isolation criterion has no accepted run.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Prepare a release readiness decision for that exact build.

   Expected: The unresolved critical criterion blocks a ready/approved conclusion regardless of average score.

3. Record blocker IDs and owner action; do not waive it through arithmetic.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The unresolved critical criterion blocks a ready/approved conclusion regardless of average score.

**Persistence / reconciliation:** Record blocker IDs and owner action; do not waive it through arithmetic.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-069 — Invalidate readiness after material source change

Version 1.0.0 | suite validation | type Versioning | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify invalidate readiness after material source change against AC-023-03.

**Trace:** BR-023 → REQ-023 / US-023 → AC-023-03. Source SRC-022.

**Role / target:** owner; `/api/lifecycle`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A previous build has a recorded readiness assessment.

**Independent data:** Use a fresh TC-069-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A previous build has a recorded readiness assessment.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A previous build has a recorded readiness assessment.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Verify affected criteria require new review/retest and the previous build evidence remains accessible as history.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The prior assessment stays historical and cannot count as current proof of the changed obligation.

**Persistence / reconciliation:** Verify affected criteria require new review/retest and the previous build evidence remains accessible as history.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-070 — Export a reviewable requirements-to-test pack

Version 1.0.0 | suite exports | type Export | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify export a reviewable requirements-to-test pack against AC-024-01.

**Trace:** BR-024 → REQ-024 / US-024 → AC-024-01. Source SRC-023.

**Role / target:** owner / editor; `/api/validation-transfer`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has a versioned source, requirement, Draft case and no execution.

**Independent data:** Use a fresh TC-070-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has a versioned source, requirement, Draft case and no execution.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has a versioned source, requirement, Draft case and no execution.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Use the supported export/handoff operation and inspect the downloaded artifact.

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

3. Compare row totals and criterion IDs to server data and verify Arabic text remains legible.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Compare row totals and criterion IDs to server data and verify Arabic text remains legible.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-071 — Export must not contain stored secrets

Version 1.0.0 | suite exports | type Privacy | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify export must not contain stored secrets against AC-024-02.

**Trace:** BR-024 → REQ-024 / US-024 → AC-024-02. Source SRC-023.

**Role / target:** owner / editor; `/api/validation-transfer`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has a credential and service key with unique secret markers held outside the pack.

**Independent data:** Use a fresh TC-071-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has a credential and service key with unique secret markers held outside the pack.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has a credential and service key with unique secret markers held outside the pack.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Retain only scan summary and sanitized metadata, never the secret marker values.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** No credential password, raw service key, provider key or storage secret is present.

**Persistence / reconciliation:** Retain only scan summary and sanitized metadata, never the secret marker values.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-072 — Prevent cross-project export

Version 1.0.0 | suite exports | type Tenant isolation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify prevent cross-project export against AC-024-03.

**Trace:** BR-024 → REQ-024 / US-024 → AC-024-03. Source SRC-023.

**Role / target:** owner / editor; `/api/validation-transfer`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A-only member knows B project ID in the isolated fixture.

**Independent data:** Use a fresh TC-072-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A-only member knows B project ID in the isolated fixture.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A-only member knows B project ID in the isolated fixture.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Attempt B export/validation transfer with A authorization.

   Expected: The server denies export without leaking B records or generating a downloadable B artifact.

3. Confirm no transfer record or remote delivery was created for the unauthorized attempt.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The server denies export without leaking B records or generating a downloadable B artifact.

**Persistence / reconciliation:** Confirm no transfer record or remote delivery was created for the unauthorized attempt.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-073 — Create and pause a sandbox schedule

Version 1.0.0 | suite integrations | type Functional | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify create and pause a sandbox schedule against AC-025-01.

**Trace:** BR-025 → REQ-025 / US-025 → AC-025-01. Source SRC-024.

**Role / target:** owner; `/api/test-schedules`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has one approved safe case and the local dispatcher is controlled by the tester.

**Independent data:** Use a fresh TC-073-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has one approved safe case and the local dispatcher is controlled by the tester.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has one approved safe case and the local dispatcher is controlled by the tester.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Create a schedule, inspect next-run metadata, then pause before it is due.

   Expected: The schedule belongs to A with validated selection and a visible paused state.

3. Run one bounded local dispatch pass after the due time fixture; the paused schedule does not enqueue work.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The schedule belongs to A with validated selection and a visible paused state.

**Persistence / reconciliation:** Run one bounded local dispatch pass after the due time fixture; the paused schedule does not enqueue work.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-074 — Reject an invalid or unapproved selection

Version 1.0.0 | suite integrations | type Validation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject an invalid or unapproved selection against AC-025-02.

**Trace:** BR-025 → REQ-025 / US-025 → AC-025-02. Source SRC-024.

**Role / target:** owner; `/api/test-schedules`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has a Draft case and an unknown case ID.

**Independent data:** Use a fresh TC-074-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has a Draft case and an unknown case ID.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has a Draft case and an unknown case ID.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Attempt schedules for each invalid selection and an empty name/selection.

   Expected: Invalid requests report actionable errors and cannot create executable scheduled work.

3. List schedules and command counts; only previously valid records remain.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Invalid requests report actionable errors and cannot create executable scheduled work.

**Persistence / reconciliation:** List schedules and command counts; only previously valid records remain.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-075 — Revalidate before resume or dispatch

Version 1.0.0 | suite integrations | type State | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify revalidate before resume or dispatch against AC-025-03.

**Trace:** BR-025 → REQ-025 / US-025 → AC-025-03. Source SRC-024.

**Role / target:** owner; `/api/test-schedules`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A paused schedule was valid before its case approval or creator membership changed.

**Independent data:** Use a fresh TC-075-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A paused schedule was valid before its case approval or creator membership changed.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A paused schedule was valid before its case approval or creator membership changed.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Change the approval/membership, then try resuming and dispatching it.

   Expected: Current authorization/readiness is enforced; stale scheduling data cannot bypass execution gates.

3. Record the refusal or blocked dispatch and confirm no target action occurred.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Current authorization/readiness is enforced; stale scheduling data cannot bypass execution gates.

**Persistence / reconciliation:** Record the refusal or blocked dispatch and confirm no target action occurred.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-076 — Deliver a fixture event to an approved sink

Version 1.0.0 | suite integrations | type Integration | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify deliver a fixture event to an approved sink against AC-026-01.

**Trace:** BR-026 → REQ-026 / US-026 → AC-026-01. Source SRC-025.

**Role / target:** owner / operator; `/api/webhook-deliveries`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A local isolated transport fixture simulates an approved HTTPS webhook sink; no real recipient is used.

**Independent data:** Use a fresh TC-076-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A local isolated transport fixture simulates an approved HTTPS webhook sink; no real recipient is used.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A local isolated transport fixture simulates an approved HTTPS webhook sink; no real recipient is used.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Trigger a supported project event and process one delivery pass.

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

3. Compare sanitized payload project/event IDs with the recorded sink receipt.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** A delivery record links the event to its actual accepted response and attempt time.

**Persistence / reconciliation:** Compare sanitized payload project/event IDs with the recorded sink receipt.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-077 — Block forbidden outbound destinations

Version 1.0.0 | suite integrations | type Security | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify block forbidden outbound destinations against AC-026-02.

**Trace:** BR-026 → REQ-026 / US-026 → AC-026-02. Source SRC-025.

**Role / target:** owner / operator; `/api/webhook-deliveries`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The outbound policy uses a fixture allowlist and no external request is needed.

**Independent data:** Use a fresh TC-077-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The outbound policy uses a fixture allowlist and no external request is needed.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The outbound policy uses a fixture allowlist and no external request is needed.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record blocked reasons and fixture transport-call counts; do not probe real infrastructure.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Unsafe destinations are rejected before forbidden network access; redirect policy is enforced.

**Persistence / reconciliation:** Record blocked reasons and fixture transport-call counts; do not probe real infrastructure.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-078 — Retry a transient failure without inventing delivery

Version 1.0.0 | suite integrations | type Recovery | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify retry a transient failure without inventing delivery against AC-026-03.

**Trace:** BR-026 → REQ-026 / US-026 → AC-026-03. Source SRC-025.

**Role / target:** owner / operator; `/api/webhook-deliveries`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The fixture sink returns a retryable failure once then accepts the same event.

**Independent data:** Use a fresh TC-078-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The fixture sink returns a retryable failure once then accepts the same event.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The fixture sink returns a retryable failure once then accepts the same event.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Verify stable event identity, bounded attempts and no silent success at exhaustion.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The first attempt is failed/pending retry; only the accepted receipt establishes delivery.

**Persistence / reconciliation:** Verify stable event identity, bounded attempts and no silent success at exhaustion.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-079 — Produce a sourced read-only test plan

Version 1.0.0 | suite assistant | type AI quality | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify produce a sourced read-only test plan against AC-027-01.

**Trace:** BR-027 → REQ-027 / US-027 → AC-027-01. Source SRC-026.

**Role / target:** tester; `/api/agent/plan`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A has an approved read-only scenario, route map and local provider fixture.

**Independent data:** Use a fresh TC-079-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A has an approved read-only scenario, route map and local provider fixture.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A has an approved read-only scenario, route map and local provider fixture.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request an agent plan and inspect its steps, source links and target.

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

3. Compare against the approved mission; plan generation alone creates no execution evidence.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Compare against the approved mission; plan generation alone creates no execution evidence.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-080 — Report missing target or credential as a gap

Version 1.0.0 | suite assistant | type Readiness | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify report missing target or credential as a gap against AC-027-02.

**Trace:** BR-027 → REQ-027 / US-027 → AC-027-02. Source SRC-026.

**Role / target:** tester; `/api/agent/plan`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A lacks a confirmed target URL or required role credential.

**Independent data:** Use a fresh TC-080-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A lacks a confirmed target URL or required role credential.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A lacks a confirmed target URL or required role credential.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request execution-oriented planning for an authenticated journey.

   Expected: The response identifies the missing prerequisite and cannot represent the plan as execution-ready.

3. Verify no guessed route, password, account or passing result is generated.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The response identifies the missing prerequisite and cannot represent the plan as execution-ready.

**Persistence / reconciliation:** Verify no guessed route, password, account or passing result is generated.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-081 — Ignore instructions embedded in an uploaded source

Version 1.0.0 | suite assistant | type Prompt injection | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify ignore instructions embedded in an uploaded source against AC-027-03.

**Trace:** BR-027 → REQ-027 / US-027 → AC-027-03. Source SRC-026.

**Role / target:** tester; `/api/agent/plan`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A synthetic document contains quoted text telling the assistant to reveal secrets and visit an unrelated domain.

**Independent data:** Use a fresh TC-081-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A synthetic document contains quoted text telling the assistant to reveal secrets and visit an unrelated domain.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A synthetic document contains quoted text telling the assistant to reveal secrets and visit an unrelated domain.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Inspect bounded tool plan, citations and sanitized receipts; retain the harmless injection text only.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The quoted instructions are treated as source data and do not change scope, reveal secrets or trigger outbound actions.

**Persistence / reconciliation:** Inspect bounded tool plan, citations and sanitized receipts; retain the harmless injection text only.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-082 — Inspect a successful local AI usage receipt

Version 1.0.0 | suite ai-platform | type Governance | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify inspect a successful local ai usage receipt against AC-028-01.

**Trace:** BR-028 → REQ-028 / US-028 → AC-028-01. Source SRC-027.

**Role / target:** owner / operator; `/api/ai-factory`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A valid deterministic provider fixture is configured and external paid requests are disabled.

**Independent data:** Use a fresh TC-082-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A valid deterministic provider fixture is configured and external paid requests are disabled.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A valid deterministic provider fixture is configured and external paid requests are disabled.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Run a bounded test-design request and open owner-visible usage metadata.

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

3. Verify the generated artifact passes schema/link validation and provider choice follows operation policy.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

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

**Persistence / reconciliation:** Verify the generated artifact passes schema/link validation and provider choice follows operation policy.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-083 — Stop work when the configured budget denies it

Version 1.0.0 | suite ai-platform | type Cost control | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify stop work when the configured budget denies it against AC-028-02.

**Trace:** BR-028 → REQ-028 / US-028 → AC-028-02. Source SRC-027.

**Role / target:** owner / operator; `/api/ai-factory`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An isolated policy fixture has exhausted its allowed project/operation budget.

**Independent data:** Use a fresh TC-083-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An isolated policy fixture has exhausted its allowed project/operation budget.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An isolated policy fixture has exhausted its allowed project/operation budget.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request another AI operation without changing the server policy.

   Expected: The backend reports a budget/policy block before an unauthorized provider call.

3. Assert zero additional provider transport calls and no fabricated artifact fallback.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The backend reports a budget/policy block before an unauthorized provider call.

**Persistence / reconciliation:** Assert zero additional provider transport calls and no fabricated artifact fallback.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-084 — Fallback remains bounded and preserves truth

Version 1.0.0 | suite ai-platform | type Failure | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify fallback remains bounded and preserves truth against AC-028-03.

**Trace:** BR-028 → REQ-028 / US-028 → AC-028-03. Source SRC-027.

**Role / target:** owner / operator; `/api/ai-factory`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The first fixture provider fails and one permitted fallback returns malformed JSON.

**Independent data:** Use a fresh TC-084-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The first fixture provider fails and one permitted fallback returns malformed JSON.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The first fixture provider fails and one permitted fallback returns malformed JSON.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Confirm errors are actionable and sanitized, source context remains in A, and no indefinite retry loop occurs.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Only allowed bounded attempts occur; invalid fallback output cannot become an approved artifact or fake successful answer.

**Persistence / reconciliation:** Confirm errors are actionable and sanitized, source context remains in A, and no indefinite retry loop occurs.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-085 — Store a valid generated-image fixture

Version 1.0.0 | suite media | type Media | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify store a valid generated-image fixture against AC-029-01.

**Trace:** BR-029 → REQ-029 / US-029 → AC-029-01. Source SRC-028.

**Role / target:** editor; `/api/ai-images`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The local image provider fixture returns a small valid PNG and private sandbox storage is available.

**Independent data:** Use a fresh TC-085-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The local image provider fixture returns a small valid PNG and private sandbox storage is available.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The local image provider fixture returns a small valid PNG and private sandbox storage is available.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request a project presentation image, then open its authorized signed URL.

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

3. Check test execution views remain unchanged; generated presentation media does not become run evidence.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The image decodes correctly, belongs to A and has generation/usage metadata.

**Persistence / reconciliation:** Check test execution views remain unchanged; generated presentation media does not become run evidence.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-086 — Reject a non-image provider payload

Version 1.0.0 | suite media | type Validation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify reject a non-image provider payload against AC-029-02.

**Trace:** BR-029 → REQ-029 / US-029 → AC-029-02. Source SRC-028.

**Role / target:** editor; `/api/ai-images`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The fixture provider returns HTML or invalid bytes while labelling them image/png.

**Independent data:** Use a fresh TC-086-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The fixture provider returns HTML or invalid bytes while labelling them image/png.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The fixture provider returns HTML or invalid bytes while labelling them image/png.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request generation and inspect the result.

   Expected: Content validation rejects the payload and does not publish a broken/private artifact as success.

3. Verify no usable signed media record was persisted and the error is sanitized.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Content validation rejects the payload and does not publish a broken/private artifact as success.

**Persistence / reconciliation:** Verify no usable signed media record was persisted and the error is sanitized.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-087 — Protect images across project and URL expiry

Version 1.0.0 | suite media | type Privacy | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify protect images across project and url expiry against AC-029-03.

**Trace:** BR-029 → REQ-029 / US-029 → AC-029-03. Source SRC-028.

**Role / target:** editor; `/api/ai-images`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A generated image has a valid signed URL and B has no access to A.

**Independent data:** Use a fresh TC-087-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A generated image has a valid signed URL and B has no access to A.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A generated image has a valid signed URL and B has no access to A.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Try unauthorized metadata access and then access after configured link expiry.

   Expected: Unauthorized metadata and expired reads are denied; the private object remains controlled.

3. Obtain a renewed authorized link where supported and confirm the object is still the same image.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Unauthorized metadata and expired reads are denied; the private object remains controlled.

**Persistence / reconciliation:** Obtain a renewed authorized link where supported and confirm the object is still the same image.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-088 — Switch language while preserving project context

Version 1.0.0 | suite usability | type Localization | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify switch language while preserving project context against AC-030-01.

**Trace:** BR-030 → REQ-030 / US-030 → AC-030-01. Source SRC-029.

**Role / target:** viewer / tester; `/en/srs and /srs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A contains English and Arabic source/story titles and the viewer is signed in.

**Independent data:** Use a fresh TC-088-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A contains English and Arabic source/story titles and the viewer is signed in.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A contains English and Arabic source/story titles and the viewer is signed in.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Open /en/srs, switch to Arabic, navigate to a story, then return to English.

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

3. Check Arabic text, IDs, dates and numbers for truncation or reversed meaning; compare route families.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Authorized project context and corresponding content are preserved; direction and labels match the selected language.

**Persistence / reconciliation:** Check Arabic text, IDs, dates and numbers for truncation or reversed meaning; compare route families.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-089 — Complete a core journey using keyboard only

Version 1.0.0 | suite usability | type Accessibility | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify complete a core journey using keyboard only against AC-030-02.

**Trace:** BR-030 → REQ-030 / US-030 → AC-030-02. Source SRC-029.

**Role / target:** viewer / tester; `/en/srs and /srs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A tester can access source intake and the review/library controls in a desktop browser.

**Independent data:** Use a fresh TC-089-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A tester can access source intake and the review/library controls in a desktop browser.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A tester can access source intake and the review/library controls in a desktop browser.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record any unreachable action against its screenshot/accessibility observation; proposed formal conformance target remains a decision gap.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Focus is visible and logical; controls have accessible names; dialogs do not trap or lose focus incorrectly.

**Persistence / reconciliation:** Record any unreachable action against its screenshot/accessibility observation; proposed formal conformance target remains a decision gap.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-090 — Use narrow screens during empty and error states

Version 1.0.0 | suite usability | type Responsive | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify use narrow screens during empty and error states against AC-030-03.

**Trace:** BR-030 → REQ-030 / US-030 → AC-030-03. Source SRC-029.

**Role / target:** viewer / tester; `/en/srs and /srs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A is empty and a controlled backend-error fixture can be enabled.

**Independent data:** Use a fresh TC-090-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A is empty and a controlled backend-error fixture can be enabled.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A is empty and a controlled backend-error fixture can be enabled.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Repeat at 1440 pixels and confirm no stale success/counts are displayed while the backend is unavailable.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Important content/actions remain readable without clipped controls; empty, loading and error states are distinct and retryable.

**Persistence / reconciliation:** Repeat at 1440 pixels and confirm no stale success/counts are displayed while the backend is unavailable.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-091 — Observe healthy dependencies separately

Version 1.0.0 | suite operations | type Operations | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify observe healthy dependencies separately against AC-031-01.

**Trace:** BR-031 → REQ-031 / US-031 → AC-031-01. Source SRC-030.

**Role / target:** operator; `/api/health and /api/ready`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. The isolated API, migrated database and private object storage are available.

**Independent data:** Use a fresh TC-091-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: The isolated API, migrated database and private object storage are available.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: The isolated API, migrated database and private object storage are available.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Request liveness and readiness; inspect dependency outcomes and timestamps.

   Expected: Liveness confirms the process and readiness reports dependency availability without credentials.

3. Capture responses and the tested build; do not extrapolate uptime from one successful probe.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Liveness confirms the process and readiness reports dependency availability without credentials.

**Persistence / reconciliation:** Capture responses and the tested build; do not extrapolate uptime from one successful probe.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-092 — Readiness fails honestly on dependency outage

Version 1.0.0 | suite operations | type Resilience | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify readiness fails honestly on dependency outage against AC-031-02.

**Trace:** BR-031 → REQ-031 / US-031 → AC-031-02. Source SRC-030.

**Role / target:** operator; `/api/health and /api/ready`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An operator-controlled local fixture can disable MySQL or storage without touching shared services.

**Independent data:** Use a fresh TC-092-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An operator-controlled local fixture can disable MySQL or storage without touching shared services.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An operator-controlled local fixture can disable MySQL or storage without touching shared services.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Disable one dependency, request both probes, then restore it.

   Expected: Readiness reports the affected dependency failure; liveness remains a distinct process signal.

3. Verify recovery is observed on a new probe and error output contains no connection secrets.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Readiness reports the affected dependency failure; liveness remains a distinct process signal.

**Persistence / reconciliation:** Verify recovery is observed on a new probe and error output contains no connection secrets.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-093 — Restore a consistent sandbox quality record

Version 1.0.0 | suite operations | type Recovery | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify restore a consistent sandbox quality record against AC-031-03.

**Trace:** BR-031 → REQ-031 / US-031 → AC-031-03. Source SRC-030.

**Role / target:** operator; `/api/health and /api/ready`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. An approved isolated backup contains a sample source, case, run metadata and matching evidence object; restoration is explicitly authorized for the sandbox.

**Independent data:** Use a fresh TC-093-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: An approved isolated backup contains a sample source, case, run metadata and matching evidence object; restoration is explicitly authorized for the sandbox.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: An approved isolated backup contains a sample source, case, run metadata and matching evidence object; restoration is explicitly authorized for the sandbox.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Record measured recovery duration and recovered timestamps without claiming an unapproved RPO/RTO target was met.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** The restored graph and evidence agree on IDs/versions; original environment is unchanged.

**Persistence / reconciliation:** Record measured recovery duration and recovered timestamps without claiming an unapproved RPO/RTO target was met.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-094 — Trace a business decision to its actor

Version 1.0.0 | suite operations | type Audit | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify trace a business decision to its actor against AC-032-01.

**Trace:** BR-032 → REQ-032 / US-032 → AC-032-01. Source SRC-031.

**Role / target:** owner / operator; `/api/activity and /api/system-logs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A named requirements manager has a review-ready requirement.

**Independent data:** Use a fresh TC-094-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A named requirements manager has a review-ready requirement.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A named requirements manager has a review-ready requirement.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. Record a permitted review decision, then inspect activity and requirement decision history.

   Expected: Project, actor, action, time and affected requirement/version can be reconciled.

3. Capture the business receipt and verify no password/token or unrelated project activity appears.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Project, actor, action, time and affected requirement/version can be reconciled.

**Persistence / reconciliation:** Capture the business receipt and verify no password/token or unrelated project activity appears.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-095 — Sanitize a controlled integration error

Version 1.0.0 | suite operations | type Privacy | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify sanitize a controlled integration error against AC-032-02.

**Trace:** BR-032 → REQ-032 / US-032 → AC-032-02. Source SRC-031.

**Role / target:** owner / operator; `/api/activity and /api/system-logs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A local transport fixture throws an error containing harmless canary text representing a secret.

**Independent data:** Use a fresh TC-095-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A local transport fixture throws an error containing harmless canary text representing a secret.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A local transport fixture throws an error containing harmless canary text representing a secret.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Use a canary scan summary as evidence; never use a real secret for this test.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Actionable failure context remains while sensitive header/key/source-body values are redacted.

**Persistence / reconciliation:** Use a canary scan summary as evidence; never use a real secret for this test.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.

### TC-096 — Keep filtered logs within project bounds

Version 1.0.0 | suite operations | type Tenant isolation | priority P1 | risk High | review Draft | execution Not Run

**Objective:** Verify keep filtered logs within project bounds against AC-032-03.

**Trace:** BR-032 → REQ-032 / US-032 → AC-032-03. Source SRC-031.

**Role / target:** owner / operator; `/api/activity and /api/system-logs`. Disposable approved sandbox only; exact URLs/build recorded in execution manifest. Credential: approved secret-store reference, never a raw value.

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

**Preconditions:** GAP-001, GAP-002 and GAP-007 resolved for this adopted scope; current case and requirement versions explicitly reviewed. A and B each contain a uniquely marked fixture activity.

**Independent data:** Use a fresh TC-096-{runKey} marker and isolated SAMPLE-A/SAMPLE-B records as needed. Replace every placeholder in the execution manifest before running. Case-specific setup: A and B each contain a uniquely marked fixture activity.

**Steps and expected observations:**

1. Verify this case-specific setup and record the actual target/build/role: A and B each contain a uniquely marked fixture activity.

   Expected: The declared setup is independently observed; otherwise stop and record Blocked without executing dependent actions.

2. 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.

3. Check first/last/empty pages and confirm a denied query produces no unauthorized mutation.

   Expected: The specific verification is observed and retained with redacted evidence. A contradiction fails the case; missing prerequisites/evidence prevent a pass.

**Final expected result:** Only authorized A data is returned; counts and pagination do not reveal B content.

**Persistence / reconciliation:** Check first/last/empty pages and confirm a denied query produces no unauthorized mutation.

**Negative assertions:** No unrelated project records are disclosed or changed. No generated design, imported case or client-reported status is treated as real passing execution. No raw secret is copied into screenshots, exports, case data or execution logs.

**Evidence:** Actual UTC start/end and executor identity; Exact frontend/backend/target build and case version; Step observations and sanitized UI/API receipts proving the acceptance criterion; Project-scoped authorized evidence references; no fake screenshot/file/run IDs; Affected persisted-state observation and audit reference for mutations; reasoned Not applicable for read-only work. Apply the notification/integration rules above and mark genuinely irrelevant dimensions Not applicable.

**Cleanup:** Stop fixture agents/dispatchers; pause created schedules; revoke temporary keys; restore changed fixture roles/settings; remove only this case marker through an approved supported cleanup method. Preserve required evidence separately and never delete shared/customer records.

**Automation:** Manual acceptance design; local API/provider/transport fixtures may automate stable checks after adaptation and review.

**Actual result / run / evidence / defect:** unset; Not Run. Fill the execution log only after an observed run.