PentaScope · Master reference pack

Reference, review, then execute

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.

Start with the business rules and open decisions. Follow stable IDs from BRD to requirements, acceptance criteria and cases. Bind your own approved project, target and build before using the execution templates.

01 · Understand the businessScope, actors, goals, 32 obligations and ten decisions.02 · Review the specificationDetailed stories, data rules, permissions and observable criteria.03 · Test with real evidenceSearch 96 designs; record observations in the blank logs.

100% designed link coverage refers only to this authored functional set. Approved, executed and passed coverage are 0%. Quantitative performance/recovery targets and adoption decisions remain open.

Printed reference: all test cases are expanded. Draft — no execution evidence.

Business requirements document

Document control and authority

Artifact BRD-MASTER-001; version 1.0.0; owner role Product Owner; reviewer role Business Analyst and Test Lead; status Draft; approval actor/date unset. The sample namespace is SAMPLE-PENTASCOPE-MASTER; it is intentionally not a real server project ID. Every proposed rule below is a recommendation grounded in local product surfaces, not an approved customer obligation. See source-manifest.json for file paths, snapshot versions and hashes. Any adopted copy must supply project-owned source references before generation or execution gates can pass.

Executive business purpose

PentaScope connects source documents, requirements decisions, test design, browser execution, evidence, defects, retests and release decisions. The business outcome is a reviewable chain from an approved obligation to observed behavior. The product is a quality and requirements application; it does not implement an ERP customer's business transactions itself.

The sample journey starts with a named account and an empty project. The business analyst explicitly uploads a versioned BRD or SRS, resolves ambiguities and submits requirements for review. A test lead designs or imports cases, verifies coverage and prepares an approved safe target. An authorized agent or tester records actual execution. A reviewer triages a failed expectation, engineering delivers an identified build, QA retests that build and a named release owner decides readiness.

Business problem and value

Requirements scattered across files lose provenance and approval context; source IDs/hashes and decision history make obligations reviewable.
Test counts are often confused with proof; separate designed/approved/executed/passed coverage keeps the decision honest.
A fixed issue can be closed against the wrong build; exact-build retest evidence prevents premature closure.
Shared tokens and cross-project caches leak responsibility or data; named membership and project scope preserve accountability.
Unbounded AI retries and unsupported output increase cost and uncertainty; registered task policy and validation constrain both.

Stakeholders and responsibilities

Sponsor / Product Owner: define business outcomes, accept scope and resolve blocking assumptions; name a release owner.
Business Analyst / requirements manager: inventory sources, preserve mandatory obligations, resolve findings and maintain immutable requirement revisions.
Test Lead / tester: approve test design, choose risk coverage, own test data and evidence quality, maintain execution logs.
Engineer: deliver fixes with build and delivery references; engineering claims are inputs to retest, not acceptance evidence.
Named reviewer: perform the permitted review decisions; this is a responsibility granted by capabilities, not a separate membership role.
Operator / security owner: manage isolated infrastructure, secret references, policies, backups and failure fixtures.
Viewer: read authorized project data and evidence without mutating it.
Widget/Agent integrations: perform narrowly scoped capture or execution actions under restricted service keys.

Scope

In scope: identity, sessions/MFA, memberships/service keys, project isolation, typed intake, durable analysis, obligation coverage, requirements and story revisions, test import/design, execution preview/commands/credentials, assertions/evidence, defects/retest, impact/coverage/release, export/handoff, schedules/webhooks, assistant/AI governance, generated presentation media, bilingual accessibility and operations.

Out of scope: implementing external customer systems; live customer data; auto-seeding a project with this pack; direct vendor billing or pricing promises; running invasive production security/load tests; legal policy invention; external emails/webhooks/paid model calls without explicit authorization; claiming every deployed bug has been found.

Proposed measurable business outcomes

100% of adopted mandatory source obligations have explicit reviewed disposition; owner Business Analyst; source ledger denominator frozen by version/hash.
100% of critical adopted criteria have approved test designs before execution sign-off; owner Test Lead; denominator is current in-scope critical criteria.
100% of claimed passing cases have attributable real observations and evidence; owner Test Lead; measure evidence-complete passes / claimed passes.
0 unauthorized project-data reads or writes in the adopted isolation matrix; owner Security Lead; scope limited to actual executed cases.
100% of closed defects reference valid matching-build retest evidence under current closure policy; owner Release Owner.
AI cost per accepted artifact, artifact review rejection rate and source coverage completion time are measured; numeric business targets require sponsor decisions before acceptance.

These targets are proposed acceptance recommendations. No measurements have been performed. Do not interpret a 100% design-link count as achievement of the business outcomes above.

Business rules and obligation ledger

Each BR maps to one OBL and a detailed REQ/US; its three acceptance criteria map to distinct cases. The ledger records draft formal disposition, not a reviewed exclusion or an automated completeness assertion about other projects.

BR-001 — Named account registration and recovery

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: account holder. Source: SRC-001 (pentascope-be/lib/account-auth.ts). Obligation OBL-001 → REQ-001 → US-001. Acceptance cases: TC-001, TC-002, TC-003.

BR-002 — Session revocation and MFA

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: account holder. Source: SRC-002 (pentascope-be/app/api/account-mfa/route.ts). Obligation OBL-002 → REQ-002 → US-002. Acceptance cases: TC-004, TC-005, TC-006.

BR-003 — Project creation and strict data isolation

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner. Source: SRC-003 (pentascope-be/app/api/account-projects/route.ts). Obligation OBL-003 → REQ-003 → US-003. Acceptance cases: TC-007, TC-008, TC-009.

BR-004 — Membership and invitation governance

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner. Source: SRC-004 (pentascope-be/app/api/project-members/route.ts). Obligation OBL-004 → REQ-004 → US-004. Acceptance cases: TC-010, TC-011, TC-012.

BR-005 — Restricted integration keys

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner / service agent. Source: SRC-005 (pentascope-be/db/runtime.ts). Obligation OBL-005 → REQ-005 → US-005. Acceptance cases: TC-013, TC-014, TC-015.

BR-006 — Typed document intake and file safety

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: editor. Source: SRC-006 (pentascope-be/app/api/project-documents/route.ts). Obligation OBL-006 → REQ-006 → US-006. Acceptance cases: TC-016, TC-017, TC-018.

BR-007 — Durable analysis and recovery

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: editor / operator. Source: SRC-007 (pentascope-be/lib/analysis-job-queue.ts). Obligation OBL-007 → REQ-007 → US-007. Acceptance cases: TC-019, TC-020, TC-021.

BR-008 — Source obligation coverage and gaps

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: requirements manager. Source: SRC-008 (pentascope-be/lib/document-analysis-policy.ts). Obligation OBL-008 → REQ-008 → US-008. Acceptance cases: TC-022, TC-023, TC-024.

BR-009 — Detailed BRD to SRS transformation

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: business analyst. Source: SRC-009 (pentascope-be/skills/pentascope-requirements-to-quality/references/stage-contracts.md). Obligation OBL-009 → REQ-009 → US-009. Acceptance cases: TC-025, TC-026, TC-027.

BR-010 — Requirement decisions and immutable revisions

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: requirements manager. Source: SRC-010 (pentascope-be/app/api/requirements-management/route.ts). Obligation OBL-010 → REQ-010 → US-010. Acceptance cases: TC-028, TC-029, TC-030.

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: viewer. Source: SRC-011 (pentascope-be/app/api/project-traceability/route.ts). Obligation OBL-011 → REQ-011 → US-011. Acceptance cases: TC-031, TC-032, TC-033.

BR-012 — Story change and language preservation

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: editor. Source: SRC-012 (pentascope-be/app/api/story-translate/route.ts). Obligation OBL-012 → REQ-012 → US-012. Acceptance cases: TC-034, TC-035, TC-036.

BR-013 — Imported test cases retain identity and quality gaps

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: tester. Source: SRC-013 (pentascope-be/lib/phase1-quality.ts). Obligation OBL-013 → REQ-013 → US-013. Acceptance cases: TC-037, TC-038, TC-039.

BR-014 — Risk-based test design and delta generation

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: tester. Source: SRC-014 (pentascope-be/app/api/story-test-generation/route.ts). Obligation OBL-014 → REQ-014 → US-014. Acceptance cases: TC-040, TC-041, TC-042.

BR-015 — Test library selection and approval readiness

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: tester. Source: SRC-015 (pentascope-be/lib/test-library.ts). Obligation OBL-015 → REQ-015 → US-015. Acceptance cases: TC-043, TC-044, TC-045.

BR-016 — Execution preview bound to target and versions

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: tester. Source: SRC-016 (pentascope-be/app/api/execution-previews/route.ts). Obligation OBL-016 → REQ-016 → US-016. Acceptance cases: TC-046, TC-047, TC-048.

BR-017 — Credential storage and scoped leases

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner / service agent. Source: SRC-017 (pentascope-be/app/api/project-credentials/[id]/lease/route.ts). Obligation OBL-017 → REQ-017 → US-017. Acceptance cases: TC-049, TC-050, TC-051.

BR-018 — Command claims, progress and recovery

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: agent:execute. Source: SRC-018 (pentascope-be/lib/test-command-service.ts). Obligation OBL-018 → REQ-018 → US-018. Acceptance cases: TC-052, TC-053, TC-054.

BR-019 — Verifiable assertions and private evidence

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: agent:execute / tester. Source: SRC-019 (pentascope-be/lib/execution-evidence.ts). Obligation OBL-019 → REQ-019 → US-019. Acceptance cases: TC-055, TC-056, TC-057.

BR-020 — Defect capture and human triage

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: tester / editor. Source: SRC-020 (pentascope-be/app/api/issues/[id]/route.ts). Obligation OBL-020 → REQ-020 → US-020. Acceptance cases: TC-058, TC-059, TC-060.

BR-021 — Fix delivery and exact-build retest

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: editor / tester. Source: SRC-020 (pentascope-be/app/api/issues/[id]/route.ts). Obligation OBL-021 → REQ-021 → US-021. Acceptance cases: TC-061, TC-062, TC-063.

BR-022 — Change impact and regression selection

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: editor. Source: SRC-021 (pentascope-be/lib/project-impact-engine.ts). Obligation OBL-022 → REQ-022 → US-022. Acceptance cases: TC-064, TC-065, TC-066.

BR-023 — Coverage arithmetic and release decisions

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner. Source: SRC-022 (pentascope-be/app/api/lifecycle/route.ts). Obligation OBL-023 → REQ-023 → US-023. Acceptance cases: TC-067, TC-068, TC-069.

BR-024 — Portable exports and controlled handoff

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner / editor. Source: SRC-023 (pentascope-be/app/api/validation-transfer/route.ts). Obligation OBL-024 → REQ-024 → US-024. Acceptance cases: TC-070, TC-071, TC-072.

BR-025 — Scheduled execution with renewed readiness

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner. Source: SRC-024 (pentascope-be/app/api/test-schedules/route.ts). Obligation OBL-025 → REQ-025 → US-025. Acceptance cases: TC-073, TC-074, TC-075.

BR-026 — Safe webhook delivery and retry

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner / operator. Source: SRC-025 (pentascope-be/lib/webhook-delivery.ts). Obligation OBL-026 → REQ-026 → US-026. Acceptance cases: TC-076, TC-077, TC-078.

BR-027 — Grounded and bounded assistant plans

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: tester. Source: SRC-026 (pentascope-be/app/api/agent/plan/route.ts). Obligation OBL-027 → REQ-027 → US-027. Acceptance cases: TC-079, TC-080, TC-081.

BR-028 — Governed AI output, privacy and budgets

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner / operator. Source: SRC-027 (pentascope-be/lib/ai-task-registry.ts). Obligation OBL-028 → REQ-028 → US-028. Acceptance cases: TC-082, TC-083, TC-084.

BR-029 — Private generated media and real content validation

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: editor. Source: SRC-028 (pentascope-be/app/api/ai-images/route.ts). Obligation OBL-029 → REQ-029 → US-029. Acceptance cases: TC-085, TC-086, TC-087.

BR-030 — Accessible bilingual and responsive workspace

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: viewer / tester. Source: SRC-029 (pentascope-fe/lib/localized-route.mjs). Obligation OBL-030 → REQ-030 → US-030. Acceptance cases: TC-088, TC-089, TC-090.

BR-031 — Readiness, backups and recovery operations

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: operator. Source: SRC-030 (pentascope-be/app/api/ready/route.ts). Obligation OBL-031 → REQ-031 → US-031. Acceptance cases: TC-091, TC-092, TC-093.

BR-032 — Auditability and sensitive-data minimization

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

Classification: recommendation. Priority: Must for this proposed master scope; risk: High. Accountable actor: owner / operator. Source: SRC-031 (pentascope-be/lib/system-log.ts). Obligation OBL-032 → REQ-032 → US-032. Acceptance cases: TC-094, TC-095, TC-096.

Assumptions and constraints

ASSUMPTION-001: a disposable environment and authorized named testers will be provided. If false, execution remains blocked.
ASSUMPTION-002: source authors will resolve product-specific rules and translations. If false, the generated artifacts remain Draft.
ASSUMPTION-003: local controlled provider/worker/transport fixtures are available for negative tests. If absent, mark those cases Blocked rather than paying for or contacting a live service.
ASSUMPTION-004: all fixture accounts, records and mailboxes are synthetic and controlled by the test team. Example domains and IDs confer no authority.
CONSTRAINT-001: the backend owns authorization, database, storage and provider work; browser code uses its frontend proxy.
CONSTRAINT-002: this master reference is a read-only static learning artifact. Runtime import and review are explicit separate user actions.

Risk register and response

RISK-001 (Critical): tenant leakage. Mitigation: independent A/B fixtures, server-side scope checks and negative read/write tests; owner Security Lead.
RISK-002 (Critical): fabricated readiness. Mitigation: exact case/build/receipt checks, separate coverage denominators and open critical gates; owner Test Lead.
RISK-003 (High): source obligation loss. Mitigation: immutable sources, obligation ledger and source coverage receipt; owner Business Analyst.
RISK-004 (High): stale edits or repeated execution. Mitigation: version checks, preview binding, command claims and bounded retry; owner Engineering.
RISK-005 (High): credentials or source text leaking into prompts/logs/exports. Mitigation: secret references, redaction and scoped private storage; owner Security Lead.
RISK-006 (High): a production target is used accidentally. Mitigation: approved manifest, visible target/build and disposable data namespace; owner Environment Owner.

Change control and acceptance

Adoption starts as a new Draft version with a named owner. Record the changed business rule, rationale, source/version, affected requirement/criterion IDs and required reviewers. Recompute traceability, invalidate stale approval and select regression from explicit links. A business rule is accepted only after an authorized decision and any required evidence; no status in this delivered pack is Approved.

Open business decisions

GAP-001 — Business authority and scope approval

Owner: Product owner. Severity: Blocking. Status: Open. These are synthetic proposed acceptance obligations. Supply project-owned BRD/SRS references and approve the adopted scope before any real project artifact is Approved.

GAP-002 — Target build, routes and credentials

Owner: Test lead. Severity: Blocking. Status: Open. Record the actual frontend/backend URLs, build revisions, authorized route map, environment, memberships and secret-store references. Sample IDs and placeholder URLs are not runnable targets.

GAP-003 — Performance and capacity

Owner: Product owner / operations. Severity: Blocking for performance sign-off. Status: Open. Choose workload, data volume, concurrency, latency percentiles, measurement duration and resource limits. No production performance target is claimed here.

GAP-004 — Availability and recovery objectives

Owner: Operations / sponsor. Severity: Blocking for operations sign-off. Status: Open. Approve RPO/RTO, maintenance expectations, backup frequency and restore responsibility, then measure a real sandbox restore.

GAP-005 — Retention and deletion rules

Owner: Data owner. Severity: Blocking for privacy sign-off. Status: Open. Define per-entity retention, evidence expiry, export retention, deletion/restore behavior and applicable data obligations. This pack invents no legal policy.

GAP-006 — Accessibility acceptance standard

Owner: Product owner / accessibility lead. Severity: Blocking for accessibility sign-off. Status: Open. Confirm formal conformance level, assistive technologies, supported browsers and devices. Keyboard and narrow-screen cases are concrete checks, not a certification.

GAP-007 — Execution safety and external services

Owner: Test lead / environment owner. Severity: Blocking. Status: Open. Approve safe target/data/action scope, forbidden actions, concurrency, cleanup, email sink, outbound fixture policy and permitted AI spend. This pack requires local fixtures by default.

GAP-008 — Reviewer separation and capabilities

Owner: Product owner / security owner. Severity: Blocking. Status: Open. Confirm the current permission/decision policy including requirements:manage, reviewer assignment and any single-manager exception. Reviewer is a responsibility, not a membership role.

GAP-009 — Execution evidence and release decision

Owner: Release owner. Severity: Blocking. Status: Open. There are no observed runs, defects, fixes or release decisions in this pack. Obtain real signed/attributable receipts and review every critical criterion before sign-off.

GAP-010 — Adoption into runtime import schema

Owner: Business analyst / test lead. Severity: Blocking for import. Status: Open. JSON and CSV are reference interchange formats, not a promised direct API payload. Use typed source intake in a disposable approved project, inspect its normalization diff and map IDs before using generated runtime records.

Software requirements specification

Purpose and system context

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

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

Actor and permission baseline

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

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

Domain data dictionary

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

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

End-to-end states and exceptions

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

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

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

Detailed requirements and stories

REQ-001 — Named account registration and recovery

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

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

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-002 — Session revocation and MFA

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-003 — Project creation and strict data isolation

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-004 — Membership and invitation governance

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-005 — Restricted integration keys

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-006 — Typed document intake and file safety

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-007 — Durable analysis and recovery

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-008 — Source obligation coverage and gaps

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-009 — Detailed BRD to SRS transformation

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-010 — Requirement decisions and immutable revisions

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-012 — Story change and language preservation

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-015 — Test library selection and approval readiness

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-016 — Execution preview bound to target and versions

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-017 — Credential storage and scoped leases

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-018 — Command claims, progress and recovery

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-019 — Verifiable assertions and private evidence

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-020 — Defect capture and human triage

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-021 — Fix delivery and exact-build retest

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-022 — Change impact and regression selection

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-023 — Coverage arithmetic and release decisions

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

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

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

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

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

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

Main flow: Open traceability and release/coverage views.

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

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

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

Acceptance criteria:

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

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

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

REQ-024 — Portable exports and controlled handoff

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-025 — Scheduled execution with renewed readiness

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-026 — Safe webhook delivery and retry

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-027 — Grounded and bounded assistant plans

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-028 — Governed AI output, privacy and budgets

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-029 — Private generated media and real content validation

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-030 — Accessible bilingual and responsive workspace

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-031 — Readiness, backups and recovery operations

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

REQ-032 — Auditability and sensitive-data minimization

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

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

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

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

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

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

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

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

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

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

Acceptance criteria:

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

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

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

Non-functional acceptance and open targets

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

NFR-001 — Security and isolation

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

NFR-002 — Source and result truthfulness

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

NFR-003 — Privacy

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

NFR-004 — Reliability

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

NFR-005 — Usability and localization

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

NFR-006 — Performance and capacity

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

NFR-007 — Recovery

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

NFR-008 — Observability

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

Test case catalogue

Every case is Draft and Not Run. The expected result is an acceptance oracle; it is not an actual observation. Independent setup, exact-build recording, redacted evidence and case-owned cleanup are required.

Search ID, title, type, role or criterion

Filter by suite

96 of 96 cases shown · all Not Run

TC-001Register and verify a named accountDraft · Not Run

Functional · P1 · identity

Traceability: BR-001 → REQ-001 → US-001 → AC-001-01 → TC-001 · SRC-001
Role / target: account holder · /en/login
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-002Password and email boundaries reject invalid inputDraft · Not Run

Boundary · P1 · identity

Traceability: BR-001 → REQ-001 → US-001 → AC-001-02 → TC-002 · SRC-001
Role / target: account holder · /en/login
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-003Recovery link cannot be replayedDraft · Not Run

Security · P1 · identity

Traceability: BR-001 → REQ-001 → US-001 → AC-001-03 → TC-003 · SRC-001
Role / target: account holder · /en/login
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-004Revoke another active sessionDraft · Not Run

Security · P1 · identity

Traceability: BR-002 → REQ-002 → US-002 → AC-002-01 → TC-004 · SRC-002
Role / target: account holder · /en/account
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-005Require valid MFA at sign-inDraft · Not Run

Security · P1 · identity

Traceability: BR-002 → REQ-002 → US-002 → AC-002-02 → TC-005 · SRC-002
Role / target: account holder · /en/account
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-006Recovery code is consumed onceDraft · Not Run

Recovery · P1 · identity

Traceability: BR-002 → REQ-002 → US-002 → AC-002-03 → TC-006 · SRC-002
Role / target: account holder · /en/account
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-007Create an empty projectDraft · Not Run

Functional · P1 · projects

Traceability: BR-003 → REQ-003 → US-003 → AC-003-01 → TC-007 · SRC-003
Role / target: owner · /en/projects
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 test 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}.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-008Reject another project identifierDraft · Not Run

Tenant isolation · P1 · projects

Traceability: BR-003 → REQ-003 → US-003 → AC-003-02 → TC-008 · SRC-003
Role / target: owner · /en/projects
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 test 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}.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-009Switch projects without stale contentDraft · Not Run

State · P1 · projects

Traceability: BR-003 → REQ-003 → US-003 → AC-003-03 → TC-009 · SRC-003
Role / target: owner · /en/projects
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-010Invite and accept a viewer membershipDraft · Not Run

Functional · P1 · access

Traceability: BR-004 → REQ-004 → US-004 → AC-004-01 → TC-010 · SRC-004
Role / target: owner · /en/members
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-011Membership removal takes immediate effectDraft · Not Run

Security · P1 · access

Traceability: BR-004 → REQ-004 → US-004 → AC-004-02 → TC-011 · SRC-004
Role / target: owner · /en/members
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-012Protect the last ownerDraft · Not Run

Business rule · P1 · access

Traceability: BR-004 → REQ-004 → US-004 → AC-004-03 → TC-012 · SRC-004
Role / target: owner · /en/members
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-013Widget can submit an issue only within scopeDraft · Not Run

Authorization · P1 · access

Traceability: BR-005 → REQ-005 → US-005 → AC-005-01 → TC-013 · SRC-005
Role / target: widget:write · /api/project-access-keys
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-014Agent cannot administer project membersDraft · Not Run

Authorization · P1 · access

Traceability: BR-005 → REQ-005 → US-005 → AC-005-02 → TC-014 · SRC-005
Role / target: agent:execute · /api/project-access-keys
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 test 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.

Actions and expected observations

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.
Attempt a member update and owner-only settings change using the Agent key.Expected: The server rejects both actions and membership/settings remain unchanged.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-015Revoked key fails on its former allowed routeDraft · Not Run

Security · P1 · access

Traceability: BR-005 → REQ-005 → US-005 → AC-005-03 → TC-015 · SRC-005
Role / target: owner / service agent · /api/project-access-keys
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 test 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.

Actions and expected observations

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.
Revoke it as owner and retry a supported issue submission with that key.Expected: The revoked key cannot create another issue.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-016Upload a labelled BRD sourceDraft · Not Run

Functional · P1 · source-intake

Traceability: BR-006 → REQ-006 → US-006 → AC-006-01 → TC-016 · SRC-006
Role / target: editor · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-017Reject mismatched content and file typeDraft · Not Run

Validation · P1 · source-intake

Traceability: BR-006 → REQ-006 → US-006 → AC-006-02 → TC-017 · SRC-006
Role / target: editor · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-018Enforce the 20 MiB document ceilingDraft · Not Run

Boundary · P1 · source-intake

Traceability: BR-006 → REQ-006 → US-006 → AC-006-03 → TC-018 · SRC-006
Role / target: editor · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-019Observe a queued job through completionDraft · Not Run

Integration · P1 · source-intake

Traceability: BR-007 → REQ-007 → US-007 → AC-007-01 → TC-019 · SRC-007
Role / target: editor / operator · /api/analysis-jobs/[id]
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-020Recover a transient provider failureDraft · Not Run

Recovery · P1 · source-intake

Traceability: BR-007 → REQ-007 → US-007 → AC-007-02 → TC-020 · SRC-007
Role / target: editor / operator · /api/analysis-jobs/[id]
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-021Cancel or stop unrecoverable analysis safelyDraft · Not Run

Failure · P1 · source-intake

Traceability: BR-007 → REQ-007 → US-007 → AC-007-03 → TC-021 · SRC-007
Role / target: editor / operator · /api/analysis-jobs/[id]
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-022Preserve distinct mandatory obligationsDraft · Not Run

Business coverage · P1 · requirements

Traceability: BR-008 → REQ-008 → US-008 → AC-008-01 → TC-022 · SRC-008
Role / target: requirements manager · /api/srs-source-audit
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-023Surface a contradictory source ruleDraft · Not Run

Negative · P1 · requirements

Traceability: BR-008 → REQ-008 → US-008 → AC-008-02 → TC-023 · SRC-008
Role / target: requirements manager · /api/srs-source-audit
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-024Invalidate a stale coverage receiptDraft · Not Run

Versioning · P1 · requirements

Traceability: BR-008 → REQ-008 → US-008 → AC-008-03 → TC-024 · SRC-008
Role / target: requirements manager · /api/srs-source-audit
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-025Generate a complete reviewable storyDraft · Not Run

Content quality · P1 · requirements

Traceability: BR-009 → REQ-009 → US-009 → AC-009-01 → TC-025 · SRC-009
Role / target: business analyst · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-026Missing business threshold becomes a questionDraft · Not Run

Ambiguity · P1 · requirements

Traceability: BR-009 → REQ-009 → US-009 → AC-009-02 → TC-026 · SRC-009
Role / target: business analyst · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-027Review only the requested source sectionDraft · Not Run

Scope · P1 · requirements

Traceability: BR-009 → REQ-009 → US-009 → AC-009-03 → TC-027 · SRC-009
Role / target: business analyst · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-028Approve a reviewed requirement with no blockersDraft · Not Run

Workflow · P1 · requirements

Traceability: BR-010 → REQ-010 → US-010 → AC-010-01 → TC-028 · SRC-010
Role / target: requirements manager · /api/requirements-management
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-029Block approval with unresolved findingsDraft · Not Run

Business rule · P1 · requirements

Traceability: BR-010 → REQ-010 → US-010 → AC-010-02 → TC-029 · SRC-010
Role / target: requirements manager · /api/requirements-management
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 test 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.

Actions and expected observations

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.
Submit or attempt the approval action using an authorized manager.Expected: The gate identifies the blocking finding and does not mark the requirement Approved.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-030Reject stale concurrent editsDraft · Not Run

Concurrency · P1 · requirements

Traceability: BR-010 → REQ-010 → US-010 → AC-010-03 → TC-030 · SRC-010
Role / target: requirements manager · /api/requirements-management
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-031Read a hierarchy and story detailDraft · Not Run

Functional · P1 · requirements

Traceability: BR-011 → REQ-011 → US-011 → AC-011-01 → TC-031 · SRC-011
Role / target: viewer · /en/srs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-032Keep an unmapped requirement visibleDraft · Not Run

Coverage · P1 · requirements

Traceability: BR-011 → REQ-011 → US-011 → AC-011-02 → TC-032 · SRC-011
Role / target: viewer · /en/srs
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 test 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.

Actions and expected observations

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.
Open traceability/coverage and filter for the unmapped record.Expected: The record stays visibly unmapped and is not counted as fully route-covered.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-033Reject a cross-project traceability edgeDraft · Not Run

Tenant isolation · P1 · requirements

Traceability: BR-011 → REQ-011 → US-011 → AC-011-03 → TC-033 · SRC-011
Role / target: editor · /en/srs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-034Edit a story and inspect its historyDraft · Not Run

Versioning · P1 · requirements

Traceability: BR-012 → REQ-012 → US-012 → AC-012-01 → TC-034 · SRC-012
Role / target: editor · /api/story-edits
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-035Translate Arabic without losing obligationsDraft · Not Run

Localization · P1 · requirements

Traceability: BR-012 → REQ-012 → US-012 → AC-012-02 → TC-035 · SRC-012
Role / target: editor · /api/story-edits
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-036Preserve the story after provider failureDraft · Not Run

Failure · P1 · requirements

Traceability: BR-012 → REQ-012 → US-012 → AC-012-03 → TC-036 · SRC-012
Role / target: editor · /api/story-edits
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 test 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.

Actions and expected observations

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.
Request translation and observe the failure; reload the story.Expected: The UI/API report failure and the original story is intact.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-037Import cases with their original IDsDraft · Not Run

Import · P1 · test-design

Traceability: BR-013 → REQ-013 → US-013 → AC-013-01 → TC-037 · SRC-013
Role / target: tester · /api/project-documents
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-038Detect duplicate and unmapped casesDraft · Not Run

Quality · P1 · test-design

Traceability: BR-013 → REQ-013 → US-013 → AC-013-02 → TC-038 · SRC-013
Role / target: tester · /api/project-documents
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 test 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.

Actions and expected observations

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.
Import the file and inspect review findings and mapping.Expected: The duplicate and unknown link are visible for review; neither silently inflates verified coverage.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-039Reject execution readiness for incomplete casesDraft · Not Run

Negative · P1 · test-design

Traceability: BR-013 → REQ-013 → US-013 → AC-013-03 → TC-039 · SRC-013
Role / target: tester · /api/project-documents
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 test 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.

Actions and expected observations

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.
Inspect its readiness and attempt to include it in an execution preview.Expected: The case remains non-executable with actionable missing-field reasons.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-040Design cases for an approved business storyDraft · Not Run

Quality · P1 · test-design

Traceability: BR-014 → REQ-014 → US-014 → AC-014-01 → TC-040 · SRC-014
Role / target: tester · /api/story-test-generation
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-041Generate missing coverage without replacing existing workDraft · Not Run

Delta · P1 · test-design

Traceability: BR-014 → REQ-014 → US-014 → AC-014-02 → TC-041 · SRC-014
Role / target: tester · /api/story-test-generation
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-042Reject unsupported test references from a providerDraft · Not Run

Validation · P1 · test-design

Traceability: BR-014 → REQ-014 → US-014 → AC-014-03 → TC-042 · SRC-014
Role / target: tester · /api/story-test-generation
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 test 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.

Actions and expected observations

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.
Run generation through the backend validator.Expected: Invalid links cannot enter approved coverage; the job reports a validation gap or bounded correction.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-043Filter and select the intended test scopeDraft · Not Run

Functional · P1 · test-design

Traceability: BR-015 → REQ-015 → US-015 → AC-015-01 → TC-043 · SRC-015
Role / target: tester · /api/test-case-groups
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-044Explain mixed executable and blocked selectionDraft · Not Run

Readiness · P1 · test-design

Traceability: BR-015 → REQ-015 → US-015 → AC-015-02 → TC-044 · SRC-015
Role / target: tester · /api/test-case-groups
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-045Version change removes stale readinessDraft · Not Run

Versioning · P1 · test-design

Traceability: BR-015 → REQ-015 → US-015 → AC-015-03 → TC-045 · SRC-015
Role / target: tester · /api/test-case-groups
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-046Confirm a current safe execution previewDraft · Not Run

Workflow · P1 · execution

Traceability: BR-016 → REQ-016 → US-016 → AC-016-01 → TC-046 · SRC-016
Role / target: tester · /api/execution-previews
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-047Reject confirmation after target changeDraft · Not Run

Safety · P1 · execution

Traceability: BR-016 → REQ-016 → US-016 → AC-016-02 → TC-047 · SRC-016
Role / target: tester · /api/execution-previews
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-048Reject confirmation after membership or case changeDraft · Not Run

Concurrency · P1 · execution

Traceability: BR-016 → REQ-016 → US-016 → AC-016-03 → TC-048 · SRC-016
Role / target: tester · /api/execution-previews
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-049Store a sample credential without exposing its secretDraft · Not Run

Security · P1 · execution

Traceability: BR-017 → REQ-017 → US-017 → AC-017-01 → TC-049 · SRC-017
Role / target: owner / service agent · /api/project-credentials/[id]/lease
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-050Reject a lease from a viewer or Widget keyDraft · Not Run

Authorization · P1 · execution

Traceability: BR-017 → REQ-017 → US-017 → AC-017-02 → TC-050 · SRC-017
Role / target: owner / service agent · /api/project-credentials/[id]/lease
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 test 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.

Actions and expected observations

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.
Request its lease using each disallowed identity.Expected: Both requests are denied without credential material.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-051Reject a foreign or revoked credential leaseDraft · Not Run

Tenant isolation · P1 · execution

Traceability: BR-017 → REQ-017 → US-017 → AC-017-03 → TC-051 · SRC-017
Role / target: agent:execute · /api/project-credentials/[id]/lease
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 test 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.

Actions and expected observations

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.
Request B credential with A Agent, then revoke an A credential and request that lease.Expected: Neither foreign nor revoked credential can be leased.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-052Claim and complete a safe sandbox commandDraft · Not Run

Execution · P1 · execution

Traceability: BR-018 → REQ-018 → US-018 → AC-018-01 → TC-052 · SRC-018
Role / target: agent:execute · /api/test-commands
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-053Prevent competing agents from duplicating a claimDraft · Not Run

Concurrency · P1 · execution

Traceability: BR-018 → REQ-018 → US-018 → AC-018-02 → TC-053 · SRC-018
Role / target: agent:execute · /api/test-commands
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-054Recover from agent interruption honestlyDraft · Not Run

Recovery · P1 · execution

Traceability: BR-018 → REQ-018 → US-018 → AC-018-03 → TC-054 · SRC-018
Role / target: agent:execute · /api/test-commands
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-055Submit an objectively verifiable passing observationDraft · Not Run

Evidence · P1 · evidence

Traceability: BR-019 → REQ-019 → US-019 → AC-019-01 → TC-055 · SRC-019
Role / target: agent:execute / tester · /api/test-runs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-056Reject a reported pass contradicted by actual dataDraft · Not Run

Negative · P1 · evidence

Traceability: BR-019 → REQ-019 → US-019 → AC-019-02 → TC-056 · SRC-019
Role / target: agent:execute / tester · /api/test-runs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-057Deny expired, tampered or cross-project evidence accessDraft · Not Run

Security · P1 · evidence

Traceability: BR-019 → REQ-019 → US-019 → AC-019-03 → TC-057 · SRC-019
Role / target: agent:execute / tester · /api/test-runs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-058Capture a reproducible synthetic defectDraft · Not Run

Workflow · P1 · defects

Traceability: BR-020 → REQ-020 → US-020 → AC-020-01 → TC-058 · SRC-020
Role / target: tester / editor · /api/issues
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-059Approve or reject with a recorded reasonDraft · Not Run

Review · P1 · defects

Traceability: BR-020 → REQ-020 → US-020 → AC-020-02 → TC-059 · SRC-020
Role / target: tester / editor · /api/issues
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-060Prevent unauthorized issue closureDraft · Not Run

Authorization · P1 · defects

Traceability: BR-020 → REQ-020 → US-020 → AC-020-03 → TC-060 · SRC-020
Role / target: tester / editor · /api/issues
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 test 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.

Actions and expected observations

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.
Attempt to change it directly to Closed using the disallowed identity.Expected: The transition is rejected and the original status remains.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-061Move a delivered fix to awaiting retestDraft · Not Run

Workflow · P1 · defects

Traceability: BR-021 → REQ-021 → US-021 → AC-021-01 → TC-061 · SRC-020
Role / target: editor / tester · /api/issues/[id]
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-062Reject closure using a different build or unrelated caseDraft · Not Run

Business rule · P1 · defects

Traceability: BR-021 → REQ-021 → US-021 → AC-021-02 → TC-062 · SRC-020
Role / target: editor / tester · /api/issues/[id]
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 test 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.

Actions and expected observations

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.
Attempt closure using the unrelated or wrong-build run.Expected: The gate rejects closure and explains the mismatched evidence.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-063Close only after a real matching retestDraft · Not Run

Retest · P1 · defects

Traceability: BR-021 → REQ-021 → US-021 → AC-021-03 → TC-063 · SRC-020
Role / target: editor / tester · /api/issues/[id]
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-064Trace a requirement change to its testsDraft · Not Run

Functional · P1 · impact

Traceability: BR-022 → REQ-022 → US-022 → AC-022-01 → TC-064 · SRC-021
Role / target: editor · /api/project-impact
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-065Show uncertainty when mapping is incompleteDraft · Not Run

Negative · P1 · impact

Traceability: BR-022 → REQ-022 → US-022 → AC-022-02 → TC-065 · SRC-021
Role / target: editor · /api/project-impact
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 test 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.

Actions and expected observations

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.
Request impact and inspect coverage/gaps.Expected: The response identifies missing mappings and cannot claim no impact merely because no link exists.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-066Ground an impact answer in the selected projectDraft · Not Run

AI grounding · P1 · impact

Traceability: BR-022 → REQ-022 → US-022 → AC-022-03 → TC-066 · SRC-021
Role / target: editor · /api/project-impact
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-067Distinguish designed from executed coverageDraft · Not Run

Reporting · P1 · validation

Traceability: BR-023 → REQ-023 → US-023 → AC-023-01 → TC-067 · SRC-022
Role / target: owner · /api/lifecycle
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 test 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.

Actions and expected observations

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.
Open traceability and release/coverage views.Expected: Designed criterion coverage is 2/4 where explicit links exist; executed/passed coverage remains zero.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-068Keep a critical security gap as a release blockerDraft · Not Run

Business rule · P1 · validation

Traceability: BR-023 → REQ-023 → US-023 → AC-023-02 → TC-068 · SRC-022
Role / target: owner · /api/lifecycle
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 test 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.

Actions and expected observations

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.
Prepare a release readiness decision for that exact build.Expected: The unresolved critical criterion blocks a ready/approved conclusion regardless of average score.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-069Invalidate readiness after material source changeDraft · Not Run

Versioning · P1 · validation

Traceability: BR-023 → REQ-023 → US-023 → AC-023-03 → TC-069 · SRC-022
Role / target: owner · /api/lifecycle
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-070Export a reviewable requirements-to-test packDraft · Not Run

Export · P1 · exports

Traceability: BR-024 → REQ-024 → US-024 → AC-024-01 → TC-070 · SRC-023
Role / target: owner / editor · /api/validation-transfer
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-071Export must not contain stored secretsDraft · Not Run

Privacy · P1 · exports

Traceability: BR-024 → REQ-024 → US-024 → AC-024-02 → TC-071 · SRC-023
Role / target: owner / editor · /api/validation-transfer
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-072Prevent cross-project exportDraft · Not Run

Tenant isolation · P1 · exports

Traceability: BR-024 → REQ-024 → US-024 → AC-024-03 → TC-072 · SRC-023
Role / target: owner / editor · /api/validation-transfer
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 test 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.

Actions and expected observations

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.
Attempt B export/validation transfer with A authorization.Expected: The server denies export without leaking B records or generating a downloadable B artifact.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-073Create and pause a sandbox scheduleDraft · Not Run

Functional · P1 · integrations

Traceability: BR-025 → REQ-025 → US-025 → AC-025-01 → TC-073 · SRC-024
Role / target: owner · /api/test-schedules
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-074Reject an invalid or unapproved selectionDraft · Not Run

Validation · P1 · integrations

Traceability: BR-025 → REQ-025 → US-025 → AC-025-02 → TC-074 · SRC-024
Role / target: owner · /api/test-schedules
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 test 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.

Actions and expected observations

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.
Attempt schedules for each invalid selection and an empty name/selection.Expected: Invalid requests report actionable errors and cannot create executable scheduled work.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-075Revalidate before resume or dispatchDraft · Not Run

State · P1 · integrations

Traceability: BR-025 → REQ-025 → US-025 → AC-025-03 → TC-075 · SRC-024
Role / target: owner · /api/test-schedules
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 test 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.

Actions and expected observations

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.
Change the approval/membership, then try resuming and dispatching it.Expected: Current authorization/readiness is enforced; stale scheduling data cannot bypass execution gates.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-076Deliver a fixture event to an approved sinkDraft · Not Run

Integration · P1 · integrations

Traceability: BR-026 → REQ-026 → US-026 → AC-026-01 → TC-076 · SRC-025
Role / target: owner / operator · /api/webhook-deliveries
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-077Block forbidden outbound destinationsDraft · Not Run

Security · P1 · integrations

Traceability: BR-026 → REQ-026 → US-026 → AC-026-02 → TC-077 · SRC-025
Role / target: owner / operator · /api/webhook-deliveries
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-078Retry a transient failure without inventing deliveryDraft · Not Run

Recovery · P1 · integrations

Traceability: BR-026 → REQ-026 → US-026 → AC-026-03 → TC-078 · SRC-025
Role / target: owner / operator · /api/webhook-deliveries
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-079Produce a sourced read-only test planDraft · Not Run

AI quality · P1 · assistant

Traceability: BR-027 → REQ-027 → US-027 → AC-027-01 → TC-079 · SRC-026
Role / target: tester · /api/agent/plan
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-080Report missing target or credential as a gapDraft · Not Run

Readiness · P1 · assistant

Traceability: BR-027 → REQ-027 → US-027 → AC-027-02 → TC-080 · SRC-026
Role / target: tester · /api/agent/plan
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 test 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.

Actions and expected observations

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.
Request execution-oriented planning for an authenticated journey.Expected: The response identifies the missing prerequisite and cannot represent the plan as execution-ready.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-081Ignore instructions embedded in an uploaded sourceDraft · Not Run

Prompt injection · P1 · assistant

Traceability: BR-027 → REQ-027 → US-027 → AC-027-03 → TC-081 · SRC-026
Role / target: tester · /api/agent/plan
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-082Inspect a successful local AI usage receiptDraft · Not Run

Governance · P1 · ai-platform

Traceability: BR-028 → REQ-028 → US-028 → AC-028-01 → TC-082 · SRC-027
Role / target: owner / operator · /api/ai-factory
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-083Stop work when the configured budget denies itDraft · Not Run

Cost control · P1 · ai-platform

Traceability: BR-028 → REQ-028 → US-028 → AC-028-02 → TC-083 · SRC-027
Role / target: owner / operator · /api/ai-factory
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 test 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.

Actions and expected observations

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.
Request another AI operation without changing the server policy.Expected: The backend reports a budget/policy block before an unauthorized provider call.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-084Fallback remains bounded and preserves truthDraft · Not Run

Failure · P1 · ai-platform

Traceability: BR-028 → REQ-028 → US-028 → AC-028-03 → TC-084 · SRC-027
Role / target: owner / operator · /api/ai-factory
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-085Store a valid generated-image fixtureDraft · Not Run

Media · P1 · media

Traceability: BR-029 → REQ-029 → US-029 → AC-029-01 → TC-085 · SRC-028
Role / target: editor · /api/ai-images
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 test 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.

Actions and expected observations

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.
Request a project presentation image, then open its authorized signed URL.Expected: The image decodes correctly, belongs to A and has generation/usage metadata.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-086Reject a non-image provider payloadDraft · Not Run

Validation · P1 · media

Traceability: BR-029 → REQ-029 → US-029 → AC-029-02 → TC-086 · SRC-028
Role / target: editor · /api/ai-images
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 test 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.

Actions and expected observations

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.
Request generation and inspect the result.Expected: Content validation rejects the payload and does not publish a broken/private artifact as success.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-087Protect images across project and URL expiryDraft · Not Run

Privacy · P1 · media

Traceability: BR-029 → REQ-029 → US-029 → AC-029-03 → TC-087 · SRC-028
Role / target: editor · /api/ai-images
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 test 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.

Actions and expected observations

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.
Try unauthorized metadata access and then access after configured link expiry.Expected: Unauthorized metadata and expired reads are denied; the private object remains controlled.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-088Switch language while preserving project contextDraft · Not Run

Localization · P1 · usability

Traceability: BR-030 → REQ-030 → US-030 → AC-030-01 → TC-088 · SRC-029
Role / target: viewer / tester · /en/srs and /srs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-089Complete a core journey using keyboard onlyDraft · Not Run

Accessibility · P1 · usability

Traceability: BR-030 → REQ-030 → US-030 → AC-030-02 → TC-089 · SRC-029
Role / target: viewer / tester · /en/srs and /srs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-090Use narrow screens during empty and error statesDraft · Not Run

Responsive · P1 · usability

Traceability: BR-030 → REQ-030 → US-030 → AC-030-03 → TC-090 · SRC-029
Role / target: viewer / tester · /en/srs and /srs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-091Observe healthy dependencies separatelyDraft · Not Run

Operations · P1 · operations

Traceability: BR-031 → REQ-031 → US-031 → AC-031-01 → TC-091 · SRC-030
Role / target: operator · /api/health and /api/ready
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 test 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.

Actions and expected observations

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.
Request liveness and readiness; inspect dependency outcomes and timestamps.Expected: Liveness confirms the process and readiness reports dependency availability without credentials.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-092Readiness fails honestly on dependency outageDraft · Not Run

Resilience · P1 · operations

Traceability: BR-031 → REQ-031 → US-031 → AC-031-02 → TC-092 · SRC-030
Role / target: operator · /api/health and /api/ready
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 test 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.

Actions and expected observations

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.
Disable one dependency, request both probes, then restore it.Expected: Readiness reports the affected dependency failure; liveness remains a distinct process signal.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-093Restore a consistent sandbox quality recordDraft · Not Run

Recovery · P1 · operations

Traceability: BR-031 → REQ-031 → US-031 → AC-031-03 → TC-093 · SRC-030
Role / target: operator · /api/health and /api/ready
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-094Trace a business decision to its actorDraft · Not Run

Audit · P1 · operations

Traceability: BR-032 → REQ-032 → US-032 → AC-032-01 → TC-094 · SRC-031
Role / target: owner / operator · /api/activity and /api/system-logs
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 test 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.

Actions and expected observations

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.
Record a permitted review decision, then inspect activity and requirement decision history.Expected: Project, actor, action, time and affected requirement/version can be reconciled.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-095Sanitize a controlled integration errorDraft · Not Run

Privacy · P1 · operations

Traceability: BR-032 → REQ-032 → US-032 → AC-032-02 → TC-095 · SRC-031
Role / target: owner / operator · /api/activity and /api/system-logs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

TC-096Keep filtered logs within project boundsDraft · Not Run

Tenant isolation · P1 · operations

Traceability: BR-032 → REQ-032 → US-032 → AC-032-03 → TC-096 · SRC-031
Role / target: owner / operator · /api/activity and /api/system-logs
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 test 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.

Actions and expected observations

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.
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.
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.
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 required: 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
Notification / integration: Only controlled test sinks are allowed; when this scenario triggers no notification, record Not applicable. Use local approved fixtures for provider/worker/webhook/media failure cases; record fixture version and actual calls.
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 ID, observations, evidence and defect links: unset. Record only after execution.

Execution plan and evidence workbook guide

Purpose and plan status

Plan PLAN-MASTER-001, version 1.0.0, Draft. The plan covers 96 designed manual acceptance cases across the proposed master scope. It is not a record of tests performed. Execution owner, environment owner, reviewer, dates and build are unset. Blank fields are deliberately unresolved; do not substitute sample IDs as actual run IDs.

Roles

Test Lead owns scope, case review, independent fixtures, sequencing and defect quality. Environment Owner owns target authorization, fixture isolation, backup/rollback and cleanup. Requirements Manager owns source decisions and business oracles. Named testers record actual observations. Agent service identities perform only approved commands. Release Owner reviews residual risk and the exact-build evidence; a developer's fix claim does not substitute for this review.

Entry gate — complete before any dependent run

Copy the reference into an adopted Draft version and record actual project-owned BRD/SRS/case IDs, versions, source hashes and review decisions. Resolve GAP-001 and any critical business ambiguity.
Complete execution-manifest.json: actual application and target URLs, exact frontend/backend/target build, environment, browser, language, timezone, executor/reviewer, scope and case versions.
Provision independent SAMPLE-A/SAMPLE-B fixture projects under test-team control, named owner/editor/tester/viewer accounts and a capability-authorized requirements manager. Store secrets outside the pack and record only approved references.
Confirm safe-mode policy, forbidden actions, allowed routes, concurrency, worker controls, fixture provider behavior, mail sink and outbound transport. No customer data, live recipients, unapproved paid AI or production target actions.
Confirm database/storage readiness and reserve a disposable data namespace. Back up only when needed for a permitted fixture restore; obtain explicit environment authorization before destructive fixture setup.
Verify the selected case's preconditions, acceptance oracle and evidence capture. Mark blocked setup without proceeding. Manual-only designs do not become browser-ready by adding a route alone.
For any AI operation after adoption, supply the governed request envelope: actual projectId, mode, entryStage, project-owned sourceRefs with versions/hashes, targetRef where required, and output language. This static reference namespace is not that envelope.

Recommended sequence and scope

Wave 0: source/case review and manifest; no target mutation. Resolve all relevant open decisions and confirm independent data ownership.
Wave 1: identity, sessions, memberships, service-key isolation and an empty project (REQ-001–REQ-005). Recreate case-specific roles after any revocation test.
Wave 2: intake, jobs, obligations, SRS decisions, story links and test design/import (REQ-006–REQ-015). Use local provider fixtures for repeatable positive/negative outputs.
Wave 3: preview, credentials, commands and evidence (REQ-016–REQ-019). Start with one read-only case and concurrency 1; increase only for the explicit competing-claim fixture.
Wave 4: defects, exact-build retest, impact, coverage and exports (REQ-020–REQ-024). Create a deliberate isolated defect and real fix only if authorized; otherwise those prerequisite-dependent cases stay Blocked.
Wave 5: schedules, webhooks, assistant/AI and media (REQ-025–REQ-029). Use bounded local dispatcher and transport/provider fixtures; stop them afterward.
Wave 6: English/Arabic keyboard/responsive checks and isolated operations/audit (REQ-030–REQ-032). Recovery/load tests require their own approved objective and environment controls.

The sequence reduces setup cost but does not replace independent preconditions. Re-run a case only for a relevant change, failure investigation or planned retest. Select regression from changed obligations and explicit links rather than repeating the entire suite without reason.

Fixture catalogue

DATA-A: disposable project SAMPLE-A-{runKey} and owner A. Contains only explicitly imported synthetic markers.
DATA-B: separate project SAMPLE-B-{runKey} and owner B; A-only identities have no membership. Use B-PRIVATE-{runKey} as a harmless disclosure marker.
DATA-ROLES: separate named editor/tester/viewer and requirements-manager fixtures, with membership version recorded before/after changes.
DATA-SOURCE: this reviewed BRD/SRS copy plus tiny ambiguous, conflicting, duplicate and malformed input files. Record hashes and type/size; no customer documents.
DATA-CASES: approved-to-test known positive, Draft, manual-only, stale-version and foreign-ID cases, each with independent ID mapping.
DATA-TARGET: an approved isolated page/API with controllable correct/wrong text, HTTP status and fixed-build identity. No real user transactions.
DATA-PROVIDERS: deterministic valid/malformed/transient-failure local chat, translation and image fixtures; record fixture revision and call count.
DATA-TRANSPORT: controlled mail sink and outbound HTTP fixture; success, failure and forbidden destination behavior are simulated without probing external hosts.
DATA-OPS: disposable database/object namespace with a consistent restoration fixture. Never stop a shared dependency for a sample case.

How to use the two CSV logs

execution-log.csv contains one prefilled Not Run row per case. Make a new row for each real attempt; keep the original case version, populate run ID, build, executor, UTC times, actual result, evidence references and defect links. Do not overwrite an earlier failed attempt with a retest pass. Keep reviewStatus separate from executionStatus.

execution-step-log.csv contains one Not Run row for each of the 288 designed steps. Bind an actual run/attempt, enter what was observed, time and evidence. Step expected text is the oracle; never copy it into actualObservation without performing and observing it. If a step is irrelevant after adaptation, explicitly review the case change first.

JSON files are reference/interchange schemas, not asserted backend POST payloads. Adapt them through approved source intake and the current deployed API contract. Use the frontend UI or a verified local harness; copying an arbitrary JSON blob to an API is not part of this plan.

Result definitions and pass/fail oracle

Not Run: no attempt started. This is every delivered case's initial state.
Blocked: required target, permission, fixture, source decision or observable evidence is unavailable. Explain the blocker; dependent actions stop.
Failed: actual observed behavior contradicts an adopted acceptance criterion. Record exact step, actual/expected, build and evidence; triage impact separately.
Passed: all required steps/assertions were observed on the recorded case/build and adequate evidence supports every expected result; a claimed client status alone is insufficient.
Not applicable: a reviewed scope decision with reason and approver, not a substitute for a failing or blocked test. Keep separate from passed coverage.

These are manual worksheet labels. Map to the current backend status contract when using runtime execution; never invent an unsupported status in an API request. A run may be recorded as blocked/failed by backend validation even if a client claims Passed.

Evidence naming and redaction

Use an actual run ID folder in the approved private evidence location, with case ID/version, attempt and step in filenames. Example naming template: {actualRunId}/{caseId}/attempt-{n}/step-{n}.png; this is not an existing evidence path. Capture timestamps, URL origin/path with secret query parameters removed, build, user role, visible observation, sanitized API status/body and persisted-state proof where relevant. Save actual fixture receipts for mail/webhook/provider tests. Record authorized evidence links and renewal/expiry policy; never paste bearer values, MFA material, passwords or raw S3 credentials.

Exit gate and release review

No automatic release follows a high score. The named owner reviews current adopted source/case versions, all critical criteria, evidence completeness, test environment/build, unresolved defects, retest lineage and approved risk decisions. Critical security, integrity, evidence or source gaps block readiness. Quantitative performance/recovery/privacy/accessibility claims require their specific approved targets and checks; the current open GAPs cannot be ignored.

Report total in-scope criteria, designed criteria, approved cases, executed cases, passed cases, blocked/failed/not-run counts, evidence completeness and orphan links separately. Explicitly show exclusions and denominator changes. Preserve prior build results as history. The delivered pack's exit decision is Draft — not ready for release because no adoption approvals or executions exist.

Stop, triage, retest and cleanup

Stop on unintended target/project access, leaked fixture secret, unsafe action, unexplained state corruption or loss of evidence. Preserve sanitized observations, stop temporary agents/dispatchers, revoke temporary keys and notify the environment owner through the team's approved process. Do not contact external parties automatically. Create a defect only for an observed deviation; business ambiguity is a finding/decision instead.

Retest the linked case on the actual delivered fix build, record a new attempt with actual observations and select impacted regression. Wrong-build or unrelated passing runs cannot close the issue. Clean only explicitly owned case markers, pause schedules and restore fixture permissions/settings. Retain evidence according to the approved project policy and record cleanup completion.

Defect, retest and release templates

Truth boundary

There are zero observed defects in this sample pack. DEFECT-TEMPLATE-001 below is a blank reporting template, not a bug claim. No actual failed run, build, screenshot, delivery or closure is supplied. Synthetic scenarios in the catalogue describe what to test; they are not execution evidence.

Defect report to fill after observation

Defect ID: assigned by the actual project system; template identity DEFECT-TEMPLATE-001 is not a runtime issue ID.
Project / environment / build / browser / role: actual values from the execution manifest.
Title: concise observed deviation and trigger, e.g. a description of the specific violated adopted criterion, not a speculative root cause.
Requirement / acceptance criterion / case and version / run and attempt: actual linked IDs.
Preconditions and independent data: exact controlled fixture needed to reproduce, with secrets removed.
Steps to reproduce: ordered actual actions, not a copied generic plan.
Expected result: cite the adopted criterion/version.
Actual result: exact observed response/state/error, UTC observation time and reproducibility count.
Evidence: authorized screenshot/API/persisted-state references that prove the mismatch; no invented filenames.
Impact / severity / priority: proposed impact, affected scope and rationale; reviewed by the designated human.
Workaround: only if actually verified; otherwise unset.
Status: observed runtime status only; template remains Draft.
Assignee / triage decision / reviewer / time / reason: actual attributable records.

Distinguish defect, requirement gap and environment blocker

An actual deviation from an approved criterion is a defect candidate. Conflicting or missing business rules are requirement findings. Missing credentials, down fixtures or unavailable target builds block execution. A provider error may be an observed integration issue, but it does not prove every generated artifact is wrong. Keep these categories separate and preserve evidence for the classification decision.

Fix delivery record

Record issue ID, approved fix scope, exact revision/build, delivery reference, changed behavior, developer checks, migration/config prerequisites and deployment target. A commit or deployment is not acceptance proof. The permitted transition to Awaiting Retest requires the current backend delivery/build fields. Re-read the issue after transition to verify what was persisted.

Retest record

Record a new actual run ID, linked case version or valid lineage, the exact delivered build, executor, target, UTC times, steps, assertions, evidence and affected regression selection. Reproduce the original failure first only when safe and useful, then verify the fix. A different-build pass or unrelated case cannot prove closure. Any failure keeps the defect unresolved; record the actual permitted reopen/failed-retest transition. Closure needs the current gate's verified fully passing evidence and authorized named decision.

Release decision template

The JSON template provides: release/build/scope, approved source/case versions, coverage denominators, actual evidence references, critical gaps, open defects, accepted risks, sign-off actor/time and rationale. All execution and approval fields are unset, counts are zero and readiness is false.

Before signing, reconcile current source obligations → requirements → criteria → case versions → actual runs → evidence → issues/fixes/retests. Review security/privacy, integrity, performance/recovery targets and supported locale/device scope separately. If a critical gap remains or evidence is absent, the honest decision is not ready; no average score overrides it.

Master app walkthrough and operating guide

Start with the reference reader

Open index.html or the app's /samples/master-app/index.html link. The page works offline, searches the test catalogue and prints with case steps expanded. Download Markdown for review, CSV for worksheet editing and JSON for structured inspection. The static reader has no login, API calls or project side effects. English is the complete reference language; Arabic examples and the concise walkthrough below support bilingual review.

1. Prepare and select your own project

In the actual application, start at /en/login for English or /login for Arabic. Sign in with your named account. Use /en/projects or /projects to create/select an authorized disposable test project. Verify its environment and base URL. Open its workspace/SRS and confirm it is empty before explicit source intake. Use separate named memberships from /en/members or /members; do not share owner tokens. A reviewer is a responsibility; membership roles are owner/editor/tester/viewer, with requirements-manager capability assigned through the allowed owner flow.

2. Adopt this sample deliberately

Read BRD.md, SRS.md and the gap register with the project owner. Make an adopted copy with project-specific facts, reviewers and approved scope. Bind source document IDs, versions and hashes after upload. Never treat the sample namespace or its local file references as an existing server-owned artifact. Import only into the disposable project you explicitly selected and authorized.

Typed source intake accepts BRD, SRS and test-case documents through /api/project-documents; the supported visible source-upload flow supplies the current request contract. Choose the correct type and a matching supported file format. The route currently limits documents to 20 MiB and checks MIME/extension/content. JSON/CSV in this pack are readable reference schemas; inspect normalization and mapping after intake rather than assuming direct API compatibility.

3. Review sources and detailed requirements

Use the SRS/source workspace (/en/srs, /en/srs/document and their Arabic routes) to inspect source type/hash, job status and findings. The backend analysis worker must be configured and running. Queued or failed jobs are not completed artifacts. Review the obligation ledger, every missing/contradictory rule, detailed actor/flow/data/permission acceptance and exact source links. Use a capability-authorized requirements manager for the permitted review transitions. Record changes as new revisions and inspect impact before reusing old approvals.

4. Design or import tests

Open the project's test-library view from the workspace. Review existing cases, map exact requirement/criterion IDs, preserve imported identity and resolve duplicate/unmapped cases. Generate only the requested missing coverage using governed backend tools. Inspect steps, data, expected result, role, cleanup and evidence. Test design does not run a browser or create proof. Approve only complete current designs through the permitted workflow; manual-only cases stay manual.

5. Prepare execution

Fill execution-manifest.json and resolve target/access/safety gaps. Record actual builds and a controlled data namespace. Configure credentials through the protected project flow and retain only secret-store references in the plan. Preview the selected current cases, review target/role/counts and explicitly confirm through the UI. If case approval, membership, credential or target changes, make a fresh preview. Missing setup blocks execution.

The operator/test lead surfaces are available at /en/operator and /en/test-lead (Arabic without /en). Agent integrations use a separately issued restricted key. The Chrome extension setup is at /en/chrome-extension only if that route exists in the adopted build; the source-discovered shared route is /chrome-extension. Use the actual visible navigation/current route map instead of guessing a locale alias.

6. Run, record and triage

Execute the precise adopted case with independent setup. Record actual observations in the row and step log, including exact build, UTC timestamps and sanitized evidence. Mark Passed only when the required oracle and evidence agree. A contradicted expectation is Failed; unavailable prerequisites are Blocked. Create a defect for an observed deviation, cite its criterion and run, then let the authorized human triage it.

7. Retest and decide readiness

Record the delivered fix build and delivery reference. Retest the linked case on that same build, preserve a new attempt and check impacted regression. Close only when the permitted evidence-backed gate is satisfied. Review designed, approved, executed and passed coverage independently; an unexecuted case remains unproven. A named release owner reviews open critical gaps and residual risk before sign-off.

Role quick guide

Product Owner: accept scope, assign memberships/capabilities, resolve decisions and review release risk.
Business Analyst: preserve source obligations, refine detailed stories and map changes to downstream impact.
Test Lead / tester: review cases, bind safe targets/data, observe runs, maintain evidence and retest.
Editor / authorized reviewer: perform only capability-permitted content/decision actions; role title alone is not an approval bypass.
Viewer: inspect project sources, coverage and authorized evidence; request an owner review when a needed mutation is unavailable.
Operator: keep workers, database/storage and fixture services observable; distinguish readiness failure from liveness.
Agent/Widget: execute or capture only the narrow service scope; never administer the project as a human.

Troubleshooting

Empty project: expected before an explicit normalized source import. Verify selected project and upload/job status; do not attach unrelated reference data to fill it.
Upload rejected: confirm documentType, true format/MIME/extension, supported content and size. A renamed file is not converted by changing its extension.
Analysis queued: inspect the actual job and local/backend worker readiness. The documented backend commands are npm run analysis:watch for bounded watching and npm run analysis:dispatch for one pass, run by the authorized operator with required configuration.
AI unavailable: inspect sanitized policy/provider configuration and job error; do not fabricate a template as successful analysis. Local acceptance fixtures avoid paid calls.
Approval unavailable: check requirements:manage, current state/version, unresolved findings and reviewer decision policy. Preserve the blocker.
Preview blocked: inspect manual-only/Draft/stale cases, target and credential readiness. Review any ready-only selection explicitly.
Evidence unavailable: confirm project access, actual file existence and signed-link expiry; request a fresh authorized link rather than exposing the storage key.
Closure denied: compare delivered build, case lineage, computed retest outcome and evidence completeness. A passing unrelated run is insufficient.
Locale/view mismatch: inspect current project context, route and refreshed backend result; preserve the observed UI error with a redacted screenshot.

دليل عربي مختصر

هذه حزمة مرجعية اصطناعية بحالة مسودة؛ جميع الاختبارات لم تُنفّذ، ولا توجد أدلة نجاح أو اعتماد إصدار. افتح المشروع التجريبي المصرّح به بحسابك الشخصي، ثم ارفع مصدر BRD أو SRS بعد مراجعته. راجع المتطلبات والفجوات واربط كل معيار قبول بحالة اختبار واضحة. حدّد البيئة والإصدار والدور وبيانات الاختبار دون وضع كلمات المرور في المستند. سجّل الملاحظات الفعلية والأدلة عند التنفيذ؛ نقص المتطلبات يعني أن الاختبار محظور، وليس ناجحاً. لا تُغلق البلاغ قبل إعادة اختبار موثقة على نفس إصدار الإصلاح. الأدوار الفعلية هي المالك والمحرر والمختبر والمشاهد؛ المراجع مسؤولية وصلاحية عمل وليست دور عضوية مستقلّاً.

Arabic fixture strings: مشروع الجودة التجريبي (sample quality project), لا يمكن للمشاهد تعديل المتطلبات (viewer cannot edit requirements), and الحد الأقصى 20 ميبيبايت (20 MiB maximum). Preserve IDs and numeric limits during translation.

Glossary

BRD: business purpose, rules, scope and decisions.
SRS: testable specification of actors, behavior, data and acceptance.
Obligation: a distinct mandatory/prohibited source behavior needing disposition.
Acceptance criterion: an observable condition proving part of a requirement.
Traceability: explicit versioned links between source, requirement, criterion, case, run and evidence.
Designed coverage: criteria linked to case designs; it is not observed behavior.
Execution receipt: actual time, actor, step/assertion observation and evidence for a specific case/build.
Build: the exact delivered revision being tested; environment name alone is not a build identity.
Retest: a new observed run proving a defect's fix on its delivered build.
Regression: selected related behavior rechecked because a change could affect it.
Capability: server-enforced permission attached to a membership or restricted service scope.

Downloads and source provenance

These are reference authoring/interchange files. Import adaptation and project-specific approval are separate steps. CSV files use UTF-8 with a BOM for Arabic text; nested case structures use JSON within cells.

README.md BRD.md SRS.md TEST-CASES.md EXECUTION-PLAN.md DEFECTS-RETEST.md USER-GUIDE.md sample.json test-cases.csv traceability.csv execution-manifest.json execution-log.csv execution-step-log.csv defect-template.json release-decision-template.json gaps-decisions.csv source-manifest.json

Local discovery source manifest

Each hash records a local working-tree source snapshot at pack generation. The files ground discovered product surfaces; they are not proof that the acceptance scenarios passed or that recommendations were approved.

Source	Local path	SHA-256
SRC-001	`pentascope-be/lib/account-auth.ts`	`18b3ae3eb13ae79750016b44dd2f7821cf1cde522d9760deef11402c7ee30efb`
SRC-002	`pentascope-be/app/api/account-mfa/route.ts`	`e4d19912dc3de584e95bdf439f895e1edcd9eb907aa6685c2fe57d8f892f7135`
SRC-003	`pentascope-be/app/api/account-projects/route.ts`	`48cebaed198a18ffb2b61021bb81ad77c80c569a82e08b46c12e0470bfdc3431`
SRC-004	`pentascope-be/app/api/project-members/route.ts`	`cc1b80c3e526be48413e5a694b540cf92d2f314bf287e276d0f2829edc908254`
SRC-005	`pentascope-be/db/runtime.ts`	`1cd5989e74ae610d7a3d25caf92e77a63b7d25f852b5c2dfadda2ca13ecc9a72`
SRC-006	`pentascope-be/app/api/project-documents/route.ts`	`6b7295446abea7b2f8e9b21704611317a7c9b7c5fa83eca5fcdbdeb016ec8582`
SRC-007	`pentascope-be/lib/analysis-job-queue.ts`	`b5340516ccabab64deb8468d9ac5935b1b1de982c4fd0c1840e0bc8c78f10fa1`
SRC-008	`pentascope-be/lib/document-analysis-policy.ts`	`4ba36d6c5722e46e17116820679ceaf7d3a84bd2dc35408d161744c208b6c2b0`
SRC-009	`pentascope-be/skills/pentascope-requirements-to-quality/references/stage-contracts.md`	`dffb5d4942d7890ac6ba12a3644e0a373e0fefc616ebe8baad7a061a82b57243`
SRC-010	`pentascope-be/app/api/requirements-management/route.ts`	`bfb98ee6aec17f7b69600a4fbfa56610c601011002cddcec25569687cc7e358b`
SRC-011	`pentascope-be/app/api/project-traceability/route.ts`	`d5f100b447e0681acdff7b4b4c4dd371315f74454439ee18b765698e1c9996c4`
SRC-012	`pentascope-be/app/api/story-translate/route.ts`	`9f710b21615c93ba6a348a22c9756292b21cd9e9fcf4a2d3465f1ed612ae01ca`
SRC-013	`pentascope-be/lib/phase1-quality.ts`	`e1cc98c1e27e5e73b01c8a0f2d261aabb20f4ea737ee6d02cbb3b4879344f690`
SRC-014	`pentascope-be/app/api/story-test-generation/route.ts`	`917038a27f049017b744643d3b045d3e7e3122e99b5714ae9301d0e571db8419`
SRC-015	`pentascope-be/lib/test-library.ts`	`b35b7ee74138f5b03b4b517480fc2abd2407fdfeeb21b616826994b203fc78e6`
SRC-016	`pentascope-be/app/api/execution-previews/route.ts`	`e98757cc95255bd4d8a17b2ee2cd2c7927084f8b021aeee9c8d4419c52cdcb9d`
SRC-017	`pentascope-be/app/api/project-credentials/[id]/lease/route.ts`	`392901d14473abcbf686ef9d729af86417b2a13c9b3a530f144a4278c2064ce8`
SRC-018	`pentascope-be/lib/test-command-service.ts`	`0f4bda2ce25378629d8900a596fab4d5432069b88e407b3c8d87e58b115dae89`
SRC-019	`pentascope-be/lib/execution-evidence.ts`	`9dde5f1ebfbed2ded7b5ff20e7ed1cd3109597873289e7749b06e98fd21b5020`
SRC-020	`pentascope-be/app/api/issues/[id]/route.ts`	`a6fefd6b954dd43c5772586eb4962e8e657e4c20bf5c269cefd460d4fe091d6f`
SRC-021	`pentascope-be/lib/project-impact-engine.ts`	`999789984921391d051749e52942a271fc7714de1f45c7dd4c3b5dc91dd9fc4e`
SRC-022	`pentascope-be/app/api/lifecycle/route.ts`	`d2aae501bf85773afd0ef91fec76320288eb606dc5d99a880933180d1fed7739`
SRC-023	`pentascope-be/app/api/validation-transfer/route.ts`	`bf8a09da14fc78fadd5b010cbae701e089755a10b52fd8a64e0d11ec6dec2183`
SRC-024	`pentascope-be/app/api/test-schedules/route.ts`	`022c5b20f683db9edff8dd3cafb54b11132a8993ddb7b604465cea8ade2a7e3c`
SRC-025	`pentascope-be/lib/webhook-delivery.ts`	`df6b662d02c8af6a346d7de33b22818c9cd2484163bd4f0604463fbf5feba52b`
SRC-026	`pentascope-be/app/api/agent/plan/route.ts`	`21ae82979e4344df6a9a18fdae118228a78b263fecb62c4c50121291eb32fdb4`
SRC-027	`pentascope-be/lib/ai-task-registry.ts`	`a9e7bea8fa7cd29f667b03ee98a12891175b71abb18d5d1af0da874a3be3a9c2`
SRC-028	`pentascope-be/app/api/ai-images/route.ts`	`1dc6075789a250742e14d21eedae32cd6c6031c8c6e56e00546bb56bf8f7e4a7`
SRC-029	`pentascope-fe/lib/localized-route.mjs`	`60734b073849843ee364de919174e72bcac57a8bcfd7d06c951644b5ecb589b4`
SRC-030	`pentascope-be/app/api/ready/route.ts`	`cc13f72a42399bca5165c938abdf6abe05eb0ed6b94ecec1138685005d05a250`
SRC-031	`pentascope-be/lib/system-log.ts`	`399d8c57b28cb432242a8a443fc773dd27a21b9399a5fea2371e918ae5d94b43`

Reference, review, then execute

Business requirements document

Document control and authority

Executive business purpose

Business problem and value

Stakeholders and responsibilities

Scope

Proposed measurable business outcomes

Business rules and obligation ledger

BR-001 — Named account registration and recovery

BR-002 — Session revocation and MFA

BR-003 — Project creation and strict data isolation

BR-004 — Membership and invitation governance

BR-005 — Restricted integration keys

BR-006 — Typed document intake and file safety

BR-007 — Durable analysis and recovery

BR-008 — Source obligation coverage and gaps

BR-009 — Detailed BRD to SRS transformation

BR-010 — Requirement decisions and immutable revisions

BR-011 — Project SRS navigation and explicit links

BR-012 — Story change and language preservation

BR-013 — Imported test cases retain identity and quality gaps

BR-014 — Risk-based test design and delta generation

BR-015 — Test library selection and approval readiness

BR-016 — Execution preview bound to target and versions

BR-017 — Credential storage and scoped leases

BR-018 — Command claims, progress and recovery

BR-019 — Verifiable assertions and private evidence

BR-020 — Defect capture and human triage

BR-021 — Fix delivery and exact-build retest

BR-022 — Change impact and regression selection

BR-023 — Coverage arithmetic and release decisions

BR-024 — Portable exports and controlled handoff

BR-025 — Scheduled execution with renewed readiness

BR-026 — Safe webhook delivery and retry

BR-027 — Grounded and bounded assistant plans

BR-028 — Governed AI output, privacy and budgets

BR-029 — Private generated media and real content validation

BR-030 — Accessible bilingual and responsive workspace

BR-031 — Readiness, backups and recovery operations

BR-032 — Auditability and sensitive-data minimization

Assumptions and constraints

Risk register and response

Change control and acceptance

Open business decisions

GAP-001 — Business authority and scope approval

GAP-002 — Target build, routes and credentials

GAP-003 — Performance and capacity

GAP-004 — Availability and recovery objectives

GAP-005 — Retention and deletion rules

GAP-006 — Accessibility acceptance standard

GAP-007 — Execution safety and external services

GAP-008 — Reviewer separation and capabilities

GAP-009 — Execution evidence and release decision

GAP-010 — Adoption into runtime import schema

Software requirements specification

Purpose and system context

Actor and permission baseline

Domain data dictionary

End-to-end states and exceptions

Detailed requirements and stories

REQ-001 — Named account registration and recovery

REQ-002 — Session revocation and MFA

REQ-003 — Project creation and strict data isolation

REQ-004 — Membership and invitation governance

REQ-005 — Restricted integration keys

REQ-006 — Typed document intake and file safety

REQ-007 — Durable analysis and recovery

REQ-008 — Source obligation coverage and gaps

REQ-009 — Detailed BRD to SRS transformation

REQ-010 — Requirement decisions and immutable revisions

REQ-011 — Project SRS navigation and explicit links

REQ-012 — Story change and language preservation

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

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

REQ-015 — Test library selection and approval readiness

REQ-016 — Execution preview bound to target and versions

REQ-017 — Credential storage and scoped leases

REQ-018 — Command claims, progress and recovery

REQ-019 — Verifiable assertions and private evidence