Keep the code task bounded and the evidence honest.

# AI-Assisted Code Change Scenario Pack

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Use this pack when an engineer uses AI to inspect a repository, propose or make a bounded code change, and assemble evidence for human review. It is designed for day-to-day engineering work where the named engineer remains accountable for scope, correctness, verification, and disposition.

This pack records work; it does not authorize repository access, approve a change, merge code, release software, or waive an owning team's controls.

## Smallest Credible Starting Set

For bounded, reversible work with no protected data, external effect, or durable-state migration, complete:

1. `bounded-task-brief.md`
2. `allowed-context-manifest.md`
3. `change-plan.md`
4. `code-review-verification-checklist.md`
5. `completion-receipt.md`

Attach a runbook when its entry condition is plausible. A runbook may be referenced rather than copied when the authoritative version is already available to the operator.

## Users, Owners, and Authority

| Role | Responsibility | Authority boundary |
| --- | --- | --- |
| Requester | States the desired outcome and business constraint | May request work; cannot expand repository or release authority |
| Task owner | Accepts the brief, bounds the work, and owns completion | May stop or narrow the task; may not waive repository controls |
| Implementer | Uses AI and engineering tools within the accepted brief | May make only allowed changes in the authorized workspace |
| Reviewer | Inspects the diff, evidence, assumptions, and findings | Produces findings or a recommendation unless separately delegated decision authority |
| Verification owner | Confirms that checks are relevant, valid, and reproducible | Accepts verification evidence for the named scope |
| Decision authority | Accepts, rejects, or returns the change under repository policy | Makes the recorded disposition; approval is not produced by this pack |
| Release owner | Controls merge, deployment, exposure, and rollback when applicable | Acts only through the owning release process |

One person may hold several roles when policy permits. Record the role assignment; do not infer authority from tool access or seniority.

## Required Inputs and Entry Criteria

- A named requester, task owner, implementer, reviewer, verification owner, and decision authority.
- A repository and baseline revision that the implementer is authorized to inspect and change.
- A bounded outcome, explicit exclusions, consequence ceiling, and stop conditions.
- An allowed-context manifest that distinguishes readable, editable, generated, and forbidden material.
- Repository instructions, contribution rules, and required checks.
- A clean separation between pre-existing changes and work created for this task.
- A credible restoration point and a known escalation path.

Do not start autonomous edits when the repository target, authority, sensitive-data handling, or ownership of existing changes is unresolved.

## Working Sequence

| Stage | Required record | Result |
| --- | --- | --- |
| Bound | Bounded Task Brief | Accepted outcome, exclusions, authority, and acceptance evidence |
| Admit context | Allowed-Context Manifest | Explicit read, edit, generation, and prohibition boundaries |
| Plan | Change Plan | Reviewable file-level intent, risks, checks, and restoration path |
| Execute | Repository-native change history and evidence references | Traceable edits within the accepted plan |
| Inspect | Code-Review and Verification Checklist | Evidence-indexed findings; never automatic approval |
| Decide | Repository decision record | Accept, reject, return, narrow, or escalate |
| Close | Completion Receipt | Immutable account of actual change, evidence, disposition, and remaining work |

## Completed Walkthrough

Use `examples/bounded-api-code-change.md` to inspect all five working records completed for a two-file, reversible API response change. It shows claim-mapped tests, evidence-indexed findings, an accepted release limitation, and a repository decision that grants no merge or deployment authority.

## Runbook Selector

| Condition | Runbook |
| --- | --- |
| Generated code does not build, behaves incorrectly, or violates an invariant | `runbooks/generated-code-failure.md` |
| Inspection or edits move beyond the accepted repository, paths, task, or consequence ceiling | `runbooks/scope-escape.md` |
| Tests are irrelevant, weakened, flaky, misleading, or do not exercise the claimed behavior | `runbooks/invalid-tests.md` |
| The change introduces an undeclared dependency, accesses a credential, or exposes secret-like material | `runbooks/unexpected-dependency-or-secret.md` |
| The accepted change must be reversed after integration or release | `runbooks/rollback.md` |

## Exit and Acceptance Criteria

The work may close only when:

- the actual diff is within the accepted brief or an authorized revision of it;
- every changed file is explained and attributable;
- required checks ran against the recorded candidate and baseline;
- verification evidence is relevant, reproducible, and indexed;
- findings have an owner and disposition;
- no secret, unapproved dependency, generated artifact, or unrelated user change is hidden in the diff;
- the decision authority recorded the outcome through the repository's normal process;
- rollback or restoration remains credible for the accepted consequence; and
- the Completion Receipt names residual uncertainty and follow-up work.

## Deeper Record Triggers

Add the applicable core toolkit modules when the change:

- handles protected or personal data;
- changes prompts, retrieval, model configuration, evaluation policy, or tool permissions;
- calls an external tool or creates a durable effect;
- modifies a schema, migration, authorization boundary, or other durable state;
- crosses a trust boundary or consumes untrusted content;
- changes runtime exposure, compatibility, or rollback behavior;
- is hard to reverse; or
- raises the affected population or consequence ceiling.

Typical additions are the Decision Packet Manifest, AI Threat Model, Tool Permission Matrix, Evaluation Plan, AI Release Manifest, and Principal Design Review Checklist and Record. The source chapter for each module remains authoritative for its engineering method.

## Material Change and Reopening Triggers

Reopen the brief and affected records when the requested behavior, target repository, baseline, editable paths, dependency set, data access, external effects, test strategy, release path, population, authority, or consequence ceiling changes. Also reopen when new evidence invalidates an acceptance claim, a check proves non-deterministic, a secret is suspected, or rollback is no longer credible.

# Completed Walkthrough: Bound a Retry Header Change

Toolkit schema: `PAISEH-TK-1.0`

Scenario pack: `PAISEH-SC-ACC-1.0`

Example status: synthetic, completed, and vendor-neutral

This walkthrough shows how a team used every working template in the pack for a small API change. The names, repository, revisions, and evidence references are illustrative. No credential, production payload, or proprietary source is included.

## Common Artifact Header

| Field | Completed record |
| --- | --- |
| Artifact ID, type, and template version | `ACC-EX-014`, completed scenario, `1.0` |
| Title and purpose | Add a bounded `Retry-After` response header when the request-rate guard returns `429` |
| System and release identity | Account API; candidate `api-2026.07.18-rc2` |
| Decision and consequence in scope | Repository acceptance only; no merge, release, or production authority |
| Population and environment | All callers of one public endpoint; local and isolated CI only |
| Owner, authors, reviewers, and decision authority | Owner: API team; implementer: Mina; reviewer: Dev; repository authority: Rowan |
| Evidence references | `EV-01` through `EV-06`, retained with change record `CR-1842` |
| Known limitations | Gateway behavior is represented by a contract fixture; staging verification remains a release prerequisite |
| State and validity | Accepted by repository authority on 2026-07-18; expires if the candidate changes |
| Reopening triggers | Endpoint contract, rate-limit policy, editable paths, dependency graph, or candidate revision changes |
| Sensitivity and retention | Internal engineering metadata; retain with repository decision history |

## 1. Completed Bounded Task Brief

| Field | Completed record |
| --- | --- |
| Request and outcome | Return `Retry-After: 30` with existing `429` responses from `GET /v1/accounts/{id}` |
| Repository and baseline | `account-api`, baseline `b71c9e4` |
| Component in scope | Rate-limit response adapter and its tests |
| Consequence ceiling | Response metadata only; no authentication, quota, persistence, or status-code change |
| Editable paths | `src/http/rate-limit-response.ts`, `tests/http/rate-limit-response.test.ts` |
| Explicit exclusions | Gateway config, shared middleware, dependency files, generated clients, deployment manifests |
| Acceptance claims | `ACC-01`: existing `429` response gains a decimal-seconds header; `ACC-02`: non-`429` responses are unchanged; `ACC-03`: invalid retry values fail closed |
| Execution contract | AI may inspect the adapter, contract tests, and repository instructions; it may edit only the two named files |
| Human checkpoints | Review before edits if another file is required; repository authority decides acceptance |
| Restoration | Revert the two-file candidate diff against `b71c9e4` |

Entry disposition: `ready`. The owner confirmed scope and feasible evidence in receipt `ENT-1842-1`.

## 2. Completed Allowed-Context Manifest

| Context ID | Source and version | Allowed use | Mode | Sensitivity | Provenance |
| --- | --- | --- | --- | --- | --- |
| `CTX-01` | repository instructions at `b71c9e4` | constrain editing and checks | read | internal | repository path and revision |
| `CTX-02` | rate-limit adapter at `b71c9e4` | understand current response construction | read/edit | internal | repository blob identity |
| `CTX-03` | adapter tests at `b71c9e4` | establish behavior and add contract cases | read/edit | internal | repository blob identity |
| `CTX-04` | public API response contract `v3.2` | verify header syntax and exclusions | read | internal | contract registry receipt |

Forbidden context included environment files, credentials, production traces, unrelated worktrees, and customer payloads. Inspection found none. The workflow did not request search expansion, network access, or retention beyond the change record.

Instruction precedence was organization policy, repository instructions, then the task brief. No conflict was found. Context receipt `CTX-R-1842` records that only `CTX-01` through `CTX-04` were used.

## 3. Completed Change Plan

Diagnosis: the adapter already owns `429` response headers but omits the retry delay. The status and body are correct. Changing shared middleware would widen the task unnecessarily.

| Step | File | Intended change | Claim | Risk and checkpoint |
| --- | --- | --- | --- | --- |
| 1 | `src/http/rate-limit-response.ts` | validate the configured delay and serialize it as decimal seconds for `429` responses | `ACC-01`, `ACC-03` | stop if the adapter cannot reject invalid values locally |
| 2 | `tests/http/rate-limit-response.test.ts` | add positive, non-`429`, and invalid-value cases | `ACC-01`–`ACC-03` | assertions must fail against the baseline |

| Evidence ID | Claim | Check | Expected result |
| --- | --- | --- | --- |
| `EV-01` | boundary | candidate diff inventory | exactly two accepted files |
| `EV-02` | `ACC-01` | focused contract test | `429` includes `Retry-After: 30` |
| `EV-03` | `ACC-02` | negative contract test | other responses contain no new header |
| `EV-04` | `ACC-03` | invalid-value cases | zero, negative, and non-integer values reject before response assembly |
| `EV-05` | regression | repository unit suite | no related failure |
| `EV-06` | build | repository type and build checks | successful candidate checks |

Plan disposition: `proceed`, recorded by reviewer Dev in `PLAN-1842-2`. No material deviation occurred.

## 4. Completed Code-Review and Verification Checklist

| Evidence ID | Authoritative evidence | Candidate | Result | Limitation |
| --- | --- | --- | --- | --- |
| `EV-01` | diff inventory `DIFF-1842` | `c48a112` | two allowed files | none |
| `EV-02`–`EV-04` | focused test report `TEST-1842-A` | `c48a112` | 7 of 7 cases pass; each new case fails on baseline | isolated runner |
| `EV-05` | unit report `TEST-1842-B` | `c48a112` | 412 of 412 pass | excludes staging |
| `EV-06` | build report `BUILD-1842` | `c48a112` | type and build checks pass | gateway not exercised |

| Review check | Evidence | Result | Finding |
| --- | --- | --- | --- |
| Diff stays within the task and context boundary | `EV-01` | Pass | — |
| No dependency, secret-like value, or protected data appears | `EV-01` | Pass | — |
| Implementation matches all accepted claims | `EV-02`–`EV-04` | Pass | — |
| Tests exercise the changed branch and can detect the prior behavior | `EV-02`–`EV-04` | Pass | — |
| Repository checks are reproducible | `EV-05`, `EV-06` | Pass | — |
| Release-path behavior is verified | `EV-06` | Indeterminate | `F-01` |

| Finding ID | Observation and consequence | Required decision | State |
| --- | --- | --- | --- |
| `F-01` | Isolated CI does not prove that an upstream gateway preserves the header | Keep staging contract verification as a release condition | Accepted limitation by repository authority; reopen if the release path changes |

Reviewer recommendation: `accept` with `F-01` carried forward. This recommendation did not authorize merge or release.

## 5. Completed Completion Receipt

| Field | Actual result |
| --- | --- |
| Baseline and final candidate | `b71c9e4` → `c48a112` |
| Actual change | Validated retry delay and emitted the header in the existing `429` adapter; added three claim-mapped test groups |
| Deviations | None |
| Dependencies and generated outputs | Unchanged |
| Pre-existing changes | None in the isolated worktree |
| Evidence and findings | `EV-01`–`EV-06`; `F-01` accepted as a release condition |
| Repository disposition | `accepted` by Rowan in `REPO-DEC-1842` |
| External effects | None; merge and deployment remain outside this receipt |
| Handoff | Release owner must verify header preservation in staging before exposure |
| Restoration | Revert candidate `c48a112`; no data recovery required |

Closure checks confirmed retrievable evidence, no secret-like material, no temporary artifact requiring retention, and an owned staging follow-up. Reopen if the candidate, API contract, gateway path, retry policy, or finding disposition changes.

## Why This Is the Minimum Credible Pack

The task is bounded, reversible, and has no external effect. The five records are enough because they bind the request, context, plan, evidence findings, and final repository decision. A release manifest and operations record become necessary only when the accepted candidate moves toward deployment.

# Bounded Task Brief

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../common-artifact-header.md` first. Use this record to turn a request into an inspectable engineering task before AI-assisted inspection or editing begins.

## 1. Requested Outcome

| Field | Record |
| --- | --- |
| Request and requester | |
| User or system outcome | |
| Repository and baseline revision | |
| Component and behavior in scope | |
| Consequence ceiling | |
| Task owner and implementer | |
| Reviewer and verification owner | |
| Decision authority and decision location | |
| Time, cost, and execution limits | |

## 2. Boundary

| Category | Explicitly allowed | Explicitly excluded | Reason / owner |
| --- | --- | --- | --- |
| Repositories and worktrees | | | |
| Files and directories | | | |
| Interfaces and behavior | | | |
| Tests and fixtures | | | |
| Dependencies and generated files | | | |
| Data, credentials, and environments | | | |
| Tools, commands, and network access | | | |
| Merge, release, and external effects | | | |

- Preserve these pre-existing changes:
- Files or subsystems that require separate approval:
- Actions that always require a human checkpoint:
- Conditions that require immediate stop and escalation:

## 3. Acceptance Contract

| Claim ID | Required claim | Acceptance criterion | Evidence required | Evidence owner |
| --- | --- | --- | --- | --- |
| ACC- | | | | |

- Required repository instructions and standards:
- Required negative or failure-path behavior:
- Compatibility and non-regression obligations:
- Performance, security, privacy, or accessibility constraints:
- Explicitly accepted uncertainty:

## 4. Execution Contract

- AI may inspect:
- AI may propose:
- AI may edit:
- AI must not access, modify, disclose, or execute:
- Human checkpoint before editing:
- Human checkpoint before irreversible or external action:
- Maximum retry or correction attempts:
- Restoration point and recovery owner:
- Authoritative task log and evidence location:

## 5. Entry Decision

| Check | Evidence / record | Result | Owner |
| --- | --- | --- | --- |
| Authority is confirmed | | Ready / blocked | |
| Baseline and existing changes are captured | | Ready / blocked | |
| Context boundary is recorded | | Ready / blocked | |
| Acceptance evidence is feasible | | Ready / blocked | |
| Restoration path is credible | | Ready / blocked | |
| Required deeper toolkit records are attached | | Ready / blocked / not triggered | |

Entry disposition: `ready`, `revise`, `blocked`, or `cancelled`

Rationale, authority, date, expiry, and receipt:

## 6. Reopening Triggers

Reopen this brief for any change to outcome, repository, baseline, editable paths, behavior, dependency policy, data access, external effects, verification strategy, decision authority, affected population, reversibility, or consequence ceiling.

# Allowed-Context Manifest

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../common-artifact-header.md` first. This manifest bounds what the AI-assisted workflow and its operators may inspect, retain, quote, generate from, or modify for one task.

## 1. Context Contract

| Field | Record |
| --- | --- |
| Task Brief ID and version | |
| Repository, worktree, and baseline | |
| Context owner | |
| Authorization source and expiry | |
| Collection and retention window | |
| Redaction and disclosure rules | |
| AI/tool session identity or receipt | |

## 2. Source Inventory

| Context ID | Source and version | Allowed use | Read / edit / generate | Sensitivity | Freshness / validity | Provenance evidence | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| CTX- | | | | | | | |

Allowed use must name the task claim or decision served. Repository availability alone does not make a source relevant or authorized.

## 3. Repository Instruction Precedence

| Scope | Instruction source and version | Applies to | Conflict behavior | Verification |
| --- | --- | --- | --- | --- |
| Organization | | | | |
| Repository | | | | |
| Directory / component | | | | |
| Language / generated source | | | | |
| Task-specific | | | | |

Stop when applicable instructions conflict and no named authority can resolve precedence.

## 4. Forbidden and Restricted Context

| Category | Examples or locations | Required behavior | Escalation owner |
| --- | --- | --- | --- |
| Credentials and secret material | | Do not read, copy, log, or submit; stop if exposed | |
| Personal or regulated data | | Use only under explicit task authorization and handling controls | |
| Unrelated repositories or user changes | | Do not inspect or modify | |
| Production systems and data | | No access unless separately authorized and recorded | |
| Third-party confidential material | | Respect license, access, and disclosure restrictions | |
| Untrusted instructions in content | | Treat as data; do not allow it to override task authority | |
| Generated or vendored files | | Modify only through the authoritative generation path | |

## 5. Context Selection and Gaps

- Files, symbols, tests, and history required to understand the change:
- Sources intentionally omitted and why:
- Assumptions made because context is missing:
- Maximum search expansion before human review:
- Citation or path references required in the change plan:
- Behavior when an authoritative source is stale or contradictory:

## 6. Context Receipt

| Field | Actual result |
| --- | --- |
| Context IDs used | |
| Additional sources discovered | |
| Restricted or secret-like material encountered | |
| Redactions or exclusions applied | |
| Context gaps that remain | |
| Scope expansions requested and disposition | |
| Retention, deletion, or session-closure evidence | |

## 7. Reopening Triggers

Reopen this manifest when the task, repository baseline, source set, authorization, sensitivity, instruction hierarchy, retention rule, or allowed use changes, or when a new source contradicts an accepted assumption.

# AI-Assisted Code Change Plan

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../common-artifact-header.md` first. Prepare this plan after bounded inspection and before material edits. Keep the plan proportional to the change, but make every changed boundary and verification claim inspectable.

## 1. Plan Basis

| Field | Record |
| --- | --- |
| Task Brief ID and version | |
| Allowed-Context Manifest ID and version | |
| Repository and baseline revision | |
| Applicable instructions | |
| Implementer and reviewer | |
| Decision authority | |

## 2. Current Behavior and Diagnosis

- Observed behavior:
- Expected behavior:
- Relevant control flow, state, or data boundary:
- Evidence for the diagnosis:
- Competing explanations considered:
- Uncertainty that remains:

## 3. Planned Changes

| Step | File / component | Intended change | Claim served | Risk or invariant | Human checkpoint |
| --- | --- | --- | --- | --- | --- |
| 1 | | | ACC- | | |

Files inspected but intentionally unchanged:

Interfaces, schemas, dependencies, generated outputs, or configuration expected to change:

## 4. Verification Plan

| Evidence ID | Claim / failure path | Check or inspection | Candidate and environment | Expected result | Evidence location | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| EV- | ACC- | | | | | |

- Why these checks exercise the changed behavior:
- Required negative, boundary, and regression cases:
- Checks that cannot run locally and their replacement evidence:
- Known flaky, sampled, or environment-sensitive checks:
- Manual inspection required:

## 5. Risk, Stopping, and Restoration

| Risk / failure | Detection | Immediate stop condition | Restoration or containment | Owner |
| --- | --- | --- | --- | --- |
| | | | | |

- Protected pre-existing changes:
- Restoration point:
- Commands or procedures that require separate authority:
- Runbooks attached:

## 6. Plan Review

| Reviewer question | Finding / evidence | Disposition |
| --- | --- | --- |
| Is the plan within the accepted task and context boundary? | | |
| Is each changed file necessary? | | |
| Can the evidence prove the stated claims? | | |
| Are failure paths and restoration credible? | | |
| Has any deeper toolkit trigger fired? | | |

Plan disposition: `proceed`, `revise`, `escalate`, or `cancel`

Reviewer, authority, conditions, date, expiry, and receipt:

## 7. Material Deviation Record

Stop and revise the plan before proceeding when actual work requires a new repository, path, interface, dependency, data source, external effect, durable-state change, acceptance claim, verification method, or consequence ceiling.

| Deviation | Why discovered | Affected records and claims | Requested authority | Disposition / receipt |
| --- | --- | --- | --- | --- |
| | | | | |

# Code-Review and Verification Checklist

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../common-artifact-header.md` first. This checklist produces evidence-indexed findings. It does not approve a change, authorize merge, or replace the repository's required review and release controls.

## 1. Review Basis

| Field | Record |
| --- | --- |
| Task Brief, Context Manifest, and Change Plan versions | |
| Repository, baseline, and candidate revision | |
| Diff identity and changed-file inventory | |
| Implementer, reviewer, and verification owner | |
| Decision authority and decision location | |
| Required repository checks and policies | |

## 2. Evidence Index

| Evidence ID | Claim or check | Authoritative source / command | Candidate and environment | Result | Limitation | Reproduction reference | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| EV- | | | | | | | |

Use references, hashes, logs, reports, screenshots, or review locations that another authorized engineer can retrieve. `Tests passed` is not an evidence reference.

## 3. Boundary and Provenance Review

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Diff is limited to accepted repositories, paths, and behavior | | Pass / fail / indeterminate / not applicable | |
| Every changed file is necessary and explained | | | |
| Pre-existing user changes remain identifiable and preserved | | | |
| Repository instructions were discovered and followed | | | |
| Generated, vendored, or machine-owned files follow their source path | | | |
| No unapproved dependency, credential, secret-like value, or protected data is present | | | |
| Attribution, license, and provenance obligations are satisfied | | | |

## 4. Correctness and Failure Review

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Implementation matches each accepted claim and exclusion | | | |
| Boundary, error, refusal, and partial-failure behavior is explicit | | | |
| Inputs, outputs, state transitions, and side effects remain valid | | | |
| Concurrency, retry, idempotency, cancellation, or cleanup is addressed when relevant | | | |
| Security, privacy, and authorization assumptions are unchanged or separately reviewed | | | |
| Compatibility and migration effects are understood | | | |
| Observability or operator evidence changes are identified | | | |
| Restoration or rollback remains credible | | | |

## 5. Test Validity and Verification

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Each test maps to an accepted claim or credible failure path | | | |
| Tests exercise the changed behavior rather than only mocks or setup | | | |
| Assertions can fail for the defect or regression they claim to detect | | | |
| Negative, boundary, and non-regression cases are proportionate | | | |
| Test data and fixtures are authorized, stable, and representative enough | | | |
| Flaky, skipped, quarantined, sampled, or environment-sensitive results are disclosed | | | |
| Commands, candidate, environment, and outputs are reproducible | | | |
| Required static, build, test, and manual inspections completed | | | |

## 6. Findings Register

| Finding ID | Evidence ID(s) | Observation and consequence | Severity | Required correction or decision | Owner / due date | Verification evidence | State / reopening trigger |
| --- | --- | --- | --- | --- | --- | --- | --- |
| F- | | | | | | | |

Allowed states: `open`, `accepted risk`, `corrected`, `verified`, `deferred`, or `not reproducible`. Only the named authority may accept risk or close a finding.

## 7. Review Outcome

- Claims verified:
- Claims not verified:
- Residual uncertainty:
- Open or accepted findings:
- Reviewer recommendation: `accept`, `return`, `narrow`, `escalate`, or `no recommendation`
- Conditions and expiry:
- Decision authority, final disposition, date, and receipt:

The reviewer recommendation is advisory unless the reviewer is separately recorded as the decision authority.

## 8. Reopening Triggers

Reopen review when the candidate, baseline, diff, dependency graph, data access, test evidence, repository policy, release path, accepted finding, or consequence ceiling changes, or when post-change evidence contradicts a verified claim.

# AI-Assisted Code Change Completion Receipt

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../common-artifact-header.md` first. Create this receipt after the repository's decision. Preserve it as an immutable account of what actually changed, which evidence was considered, and what remains unresolved.

## 1. Work Identity

| Field | Actual result |
| --- | --- |
| Task Brief, Context Manifest, Change Plan, and Checklist versions | |
| Repository, baseline, and final candidate revision | |
| Work session or execution receipt | |
| Requester, task owner, implementer, reviewer, and verification owner | |
| Decision authority and repository decision reference | |
| Start, decision, completion, and expiry times | |

## 2. Actual Change

| Planned item | Actual files / behavior changed | Deviation from plan | Reason and authority | Diff / commit reference |
| --- | --- | --- | --- | --- |
| | | | | |

- Files inspected but unchanged:
- Dependencies or generated outputs changed:
- Pre-existing changes preserved:
- External actions or durable effects:

## 3. Evidence and Findings

| Claim ID | Evidence ID(s) | Actual result | Limitation or residual uncertainty |
| --- | --- | --- | --- |
| ACC- | EV- | | |

| Finding ID | Final state | Correction / accepted risk / deferral | Authority and evidence | Reopening trigger |
| --- | --- | --- | --- | --- |
| F- | | | | |

## 4. Decision and Handoff

- Final disposition: `accepted`, `rejected`, `returned`, `narrowed`, `cancelled`, or `superseded`
- Decision rationale:
- Conditions, expiry, or exposure limit:
- Merge, release, or downstream owner:
- Release or change record:
- Restoration or rollback reference:
- Operator, reviewer, or maintainer handoff:

## 5. Closure

| Closure check | Evidence / result |
| --- | --- |
| Workspace and temporary artifacts handled as required | |
| Secret-like or protected material absent or incident path completed | |
| Relevant records and evidence are retrievable | |
| Follow-up work has an owner and due date | |
| Requester or owning team received the outcome | |
| Closure authority confirmed completion | |

- Remaining work:
- Known limitations:
- Reopening triggers:
- Supersedes / superseded by:

# Runbook: Generated-Code Failure

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when AI-generated or AI-modified code fails to build, fails a relevant check, behaves incorrectly, or violates an accepted invariant.

## Entry Conditions and Authority

- Triggering evidence, candidate revision, and affected claim:
- Observed failure and consequence:
- Operator and task owner:
- Authority to edit, revert, rerun checks, or stop work:
- Separate authority required for external systems, shared environments, merge, or release:

## Immediate Action

1. Stop further scope expansion and preserve the failing candidate, command, output, and environment identity.
2. Confirm whether the failure belongs to the task candidate rather than the baseline or an unrelated user change.
3. Prevent merge, release, or downstream use while a required claim is failed or indeterminate.
4. Select correction, restoration to the accepted baseline, or escalation within the recorded authority.

## Diagnosis and Correction

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Reproduce | Run the smallest authoritative failing check against the recorded candidate | Repeatable failure or documented non-reproduction | The check is unsafe, unauthorized, or non-reproducible |
| Localize | Map failure to changed files, assumptions, inputs, state, or environment | Bounded causal hypothesis with disconfirming evidence | Diagnosis requires forbidden context or broader scope |
| Correct | Make the smallest plan-compatible correction | Explainable diff tied to the failed claim | A new dependency, interface, data access, or consequence is required |
| Reverify | Run the original check plus relevant boundary and regression checks | Evidence IDs for the same candidate | Evidence remains failed, flaky, stale, or incomplete |

Maximum correction attempts before task-owner review:

## Verification and Stopping Conditions

Recovery requires the original failure to be absent for the recorded candidate, relevant acceptance claims to have current evidence, and no unrelated changes to be concealed by the correction.

Stop and escalate when:

- the baseline also fails and ownership is unclear;
- correction requires a material plan or context change;
- the check cannot prove the claimed behavior;
- a secret, protected-data exposure, external effect, or durable-state impact is suspected; or
- the restoration point is no longer credible.

## Reversal

- Restoration point and procedure:
- Pre-existing changes to preserve:
- Generated or temporary artifacts to remove through their authoritative path:
- Evidence that restoration returned only this task's work:

## Evidence and Closure

Record the failure, reproduction, hypotheses, actions, candidate revisions, check outputs, remaining uncertainty, and decision receipt.

Close only when the task owner and verification owner confirm correction or restoration, findings have a disposition, and the Completion Receipt points to the final evidence. Reopen if the failure recurs or later evidence invalidates the correction.

# Runbook: Scope Escape

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when inspection, generation, editing, commands, or proposed behavior moves outside the accepted task, repository, path, context, authority, or consequence boundary.

## Entry Conditions and Authority

- Escaped boundary and detection evidence:
- Last known in-scope action:
- Potentially affected repositories, files, data, systems, or people:
- Operator, task owner, repository owner, and security/privacy contact when applicable:
- Authority to stop processes, preserve evidence, restore files, or revoke a session:

## Containment

1. Stop the AI-assisted workflow and any queued action. Do not ask it to repair the scope escape before containment.
2. Preserve the task log, candidate diff, commands, tool receipts, and context references.
3. Block merge, release, synchronization, or external effects from the affected candidate.
4. Isolate out-of-scope outputs without deleting evidence or overwriting pre-existing user work.
5. Escalate immediately if credentials, protected data, external systems, or another repository may have been accessed.

## Assessment and Action

| Question | Evidence | Action / authority |
| --- | --- | --- |
| What boundary was crossed? | | |
| Was content only observed, or was it retained, changed, disclosed, or executed? | | |
| Did an external or durable effect occur? | | |
| Can task-created changes be distinguished from pre-existing work? | | |
| Which permissions, sessions, caches, logs, or outputs remain active? | | |

Restore only under the repository owner's authority. Prefer a targeted inverse change or recoverable operation that preserves unrelated work and evidence.

## Verification and Stopping Conditions

Verify that active work is stopped; out-of-scope changes and effects are inventoried; permissions or sessions are contained; the authorized baseline and unrelated changes are preserved; and required incident handoffs have receipts.

Stop restoration and escalate when ownership is uncertain, the effect is irreversible, evidence would be destroyed, another person's work may be overwritten, or protected material may have left its authorized boundary.

## Reversal

- Authorized baseline and preserved user-change references:
- Targeted restoration steps:
- External compensation or reconciliation owner:
- Post-restoration diff and effect verification:

## Evidence and Closure

Record the initiating action, escaped boundary, exposure duration, affected objects, containment, restoration, access changes, notifications, findings, and authority receipts.

Close only when the owning authority accepts the inventory, containment is verified, restoration or compensation is complete or explicitly deferred, and the brief and context manifest are revised or the task is cancelled. Reopen on newly discovered access, output, disclosure, or effect.

# Runbook: Invalid or Misleading Tests

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when a test is irrelevant, weakened, flaky, skipped, stale, over-mocked, unable to fail for the claimed defect, or otherwise unsuitable as acceptance evidence.

## Entry Conditions and Authority

- Suspect test, result, and claimed acceptance evidence:
- Reason validity is in doubt:
- Candidate, environment, fixture, and command identity:
- Verification owner and authority to quarantine, replace, or rerun evidence:
- Separate authority required to change shared tests or acceptance criteria:

## Immediate Action

1. Mark every claim relying on the suspect evidence `indeterminate`.
2. Prevent the checklist or downstream decision record from presenting the result as a pass.
3. Preserve the original test, output, environment, seed, fixture, retries, and candidate identity.
4. Distinguish a defective product change from defective evidence; do not assume either.

## Test Audit and Replacement

| Audit | Required evidence | Result |
| --- | --- | --- |
| Trace test to an accepted claim or credible failure path | Claim and scenario ID | |
| Demonstrate the assertion can fail for the targeted defect | Controlled negative or mutation result | |
| Confirm the changed behavior executes | Trace, coverage, state, or observable effect | |
| Check fixtures, clocks, seeds, mocks, caches, and environment | Versioned inputs and setup | |
| Measure repetition or flake behavior when relevant | Run distribution and failure pattern | |
| Identify skipped, quarantined, sampled, or suppressed results | Runner configuration and output | |

Replace or supplement invalid evidence with the smallest authoritative check that can support the claim. Changing acceptance criteria requires the Task Brief's decision authority; changing shared test policy requires its owning authority.

## Verification and Stopping Conditions

Verification requires a recorded claim-to-check mapping, proof that the check exercises the intended behavior and can detect failure, reproducible results for the same candidate, and disclosure of remaining limitations.

Stop and escalate when no feasible check can support a required claim, the environment cannot be reproduced, valid testing requires protected data or unauthorized access, or the proposed fix weakens a shared invariant.

## Reversal

- Restore unauthorized or unjustified test changes:
- Preserve valid additions independently of the suspect result:
- Reinstate quarantines or policy state only under owning authority:
- Confirm that no acceptance claim still points to invalid evidence:

## Evidence and Closure

Record the invalid test, affected claims, audit results, replacement evidence, policy decisions, candidate, and remaining gaps.

Close only when the verification owner confirms the evidence disposition, affected findings and decision records are updated, and the decision authority accepts the resulting level of certainty. Reopen when flakiness recurs or the test environment, fixture, or behavior changes.

# Runbook: Unexpected Dependency or Secret

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when work introduces an undeclared dependency, changes a lockfile unexpectedly, requests network retrieval outside the plan, encounters a credential, or places secret-like or protected material in prompts, logs, code, tests, fixtures, artifacts, or history.

## Entry Conditions and Authority

- Trigger, candidate, file or artifact, and detection evidence:
- Suspected dependency, credential, secret, or protected-data class:
- Exposure locations and possible recipients:
- Task owner, repository/dependency owner, and security or privacy contact:
- Authority to stop work, isolate artifacts, revoke credentials, or initiate incident handling:

Do not reproduce secret values in this record. Use redacted identifiers and the authorized incident or secret-management reference.

## Immediate Action

1. Stop generation, editing, copying, upload, network retrieval, and downstream use of the affected candidate.
2. Preserve metadata and evidence without printing or redistributing the suspected value.
3. Isolate affected working artifacts and block merge or release.
4. Notify the named security or repository authority through the approved path.
5. Rotate, revoke, or invalidate credentials only under the responsible authority; deletion from one file is not containment.

## Classify and Respond

| Condition | Required action | Verification |
| --- | --- | --- |
| Undeclared package, service, model, binary, or generated dependency | Identify origin, purpose, license, integrity, transitive effects, and owner; remove or route for approval | Dependency and lockfile diff; approved source and version |
| Secret-like value with no confirmed exposure | Treat as real until classified; restrict access and inspect authorized exposure metadata | Classification and containment receipt |
| Confirmed credential or protected-data exposure | Invoke the owning incident path, revoke/rotate where applicable, and assess logs, prompts, caches, history, and recipients | Incident, revocation, purge, and notification receipts |
| False positive | Record safe classification without copying the value | Authorized classifier and rationale |

## Verification and Stopping Conditions

Verify that the dependency graph matches an approved plan or has been restored; affected credentials are invalidated when required; secret-like material is absent from reachable candidate artifacts; retained copies, logs, sessions, and history have an authorized disposition; and affected evidence is re-created safely.

Stop local remediation and escalate when exposure scope is unknown, history rewriting or third-party deletion is proposed, another user's work may be affected, regulated notification may apply, or the operator lacks revocation or dependency authority.

## Reversal

- Dependency removal or approved substitution:
- Candidate restoration point:
- Credential revocation/rotation reference:
- Authorized cache, log, artifact, or history handling:
- Re-run checks without using exposed material:

## Evidence and Closure

Record redacted identifiers, timestamps, affected locations, recipients or systems, dependency provenance, containment, revocation, removal, verification, and authority receipts.

Close only when the owning security or repository authority confirms containment, affected records and evidence are safe, dependency disposition is explicit, and required incident or policy follow-up has an owner. Reopen on new exposure evidence, downstream retrieval, or dependency drift.

# Runbook: AI-Assisted Code Change Rollback

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ACC-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when an accepted AI-assisted code change must be reversed after integration or release. The owning repository and release process remain authoritative.

## Entry Conditions and Authority

- Triggering signal, incident, finding, or decision:
- Change, merge, release, and affected population:
- Known or suspected consequence:
- Rollback decision authority:
- Operator and verifier:
- Required release, database, security, or incident handoffs:
- Last known safe version and evidence:

## Decision

| Question | Evidence | Result / authority |
| --- | --- | --- |
| Is the change the credible cause or a necessary containment target? | | |
| Is direct rollback safer than forward correction or degraded mode? | | |
| Are schema, data, protocol, queue, cache, or in-flight effects compatible? | | |
| What unrelated changes share the rollback unit? | | |
| Is reserved capacity and dependency compatibility available? | | |

Do not proceed when the rollback unit, authority, compatibility, or restoration target is unknown.

## Action Plan

| Stage | Authorized action / procedure reference | Preconditions | Expected effect | Verification | Stop condition |
| --- | --- | --- | --- | --- | --- |
| Contain | | | | | |
| Restore code/configuration | | | | | |
| Reconcile in-flight work and durable effects | | | | | |
| Verify new traffic | | | | | |
| Verify delayed or downstream effects | | | | | |

Prefer the repository's established inverse-change or release-transition path. Never overwrite unrelated user changes or remove evidence merely to recreate a clean baseline.

## Verification and Stopping Conditions

Verify effective versions, routing, new work, queued and in-flight work, durable state, external effects, behavioral outcomes, required checks, telemetry health, and affected-user remediation as applicable.

Stop and escalate when the safe target is unavailable, migration is not backward compatible, partial rollback creates mixed-state risk, reconciliation cannot determine outcomes, unrelated changes would be reversed, or evidence cannot distinguish recovery from missing telemetry.

## Reversal of the Rollback

- Conditions for reintroducing the change:
- Corrected candidate and new evidence required:
- Approval and staged exposure path:
- Expiry of temporary containment or degraded mode:

## Evidence and Closure

Record decision evidence, authority, commands or procedure receipts, effective versions, affected scope, in-flight and durable-state disposition, verification windows, remaining uncertainty, communications, and follow-up findings.

Close only when the rollback authority and verification owner confirm the intended safe state, external or durable effects are reconciled or explicitly owned, and the Completion Receipt and release or incident record agree. Reopen on recurrence, delayed effects, version drift, or telemetry gaps.