# Execution plan and evidence workbook guide

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

## Purpose and 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

1. 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.
2. Complete execution-manifest.json: actual application and target URLs, exact frontend/backend/target build, environment, browser, language, timezone, executor/reviewer, scope and case versions.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.