diff --git a/plugins/staged-implementation/.codex-plugin/plugin.json b/plugins/staged-implementation/.codex-plugin/plugin.json
index 6fccd00..14bceb1 100644
--- a/plugins/staged-implementation/.codex-plugin/plugin.json
+++ b/plugins/staged-implementation/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "staged-implementation",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Planner, implementer, validator, and orchestrator skills for staged implementation workflows.",
   "author": {
     "name": "Local developer"
diff --git a/plugins/staged-implementation/skills/implementer/SKILL.md b/plugins/staged-implementation/skills/implementer/SKILL.md
index 523a53d..568327a 100644
--- a/plugins/staged-implementation/skills/implementer/SKILL.md
+++ b/plugins/staged-implementation/skills/implementer/SKILL.md
@@ -53,6 +53,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
 5. Validate.
    - Run the validation commands requested in the prompt when feasible.
    - Run targeted additional checks only when they directly reduce risk for the edited surface.
+   - For corrections, identify affected behavior/consumers and rerun affected checks. Reuse evidence only when the assignment permits it and relevant inputs still match; retain original limits. Rerun if applicability is uncertain. Never skip a required fresh check or broaden into unrelated matrices/harnesses.
    - If a command must be adjusted, report the exact adjustment and why.
    - If validation cannot run, report the blocker clearly.
 
@@ -65,7 +66,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
 
 7. Report results.
    - Summarize changed files and behavior.
-   - List validations run and their results.
+   - Distinguish fresh validation from verified reused evidence; give results/artifact paths instead of repeating full logs. Retain raw evidence and inspect failures/unexpected output.
    - List blockers, ambiguities, or residual risk.
    - Include the requested contract verification matrix for contract-heavy chunks.
    - Always propose a one-line commit message unless the user explicitly asks not to. If the prompt defines a chunk ID, start the message with that exact prefix.
diff --git a/plugins/staged-implementation/skills/orchestrator/SKILL.md b/plugins/staged-implementation/skills/orchestrator/SKILL.md
index 70fc533..d90f70a 100644
--- a/plugins/staged-implementation/skills/orchestrator/SKILL.md
+++ b/plugins/staged-implementation/skills/orchestrator/SKILL.md
@@ -48,12 +48,12 @@ Before delegating implementation, run a readiness preflight:
 
 1. Establish current state.
    - Read project instructions first.
-   - Read the plan, checklist, prompt map, recent review notes, and relevant git/worktree state.
+   - Establish context from the plan, checklist, prompt map, current handoff/review and relevant git/worktree state. On continuation, read changed instructions/contracts and affected scope rather than reloading unchanged history.
    - Read any existing readiness audit. If no readiness audit exists, create one before writing the first implementer prompt.
-   - Inspect every chunk and classify it as `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`.
+   - Initially classify every chunk as `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`. Subsequently verify affected entries/dependencies; broaden when a shared contract changes or applicability is uncertain.
    - Surface all contract blockers and small freezes to the user before implementation starts.
    - Stop if any `blocked-by-contract-decision` item remains unresolved, unless the user explicitly authorizes implementing only the `ready` subset while blocked chunks remain held.
-   - Stop if a `needs-small-freeze-before-prompt` item affects the next implementation path and cannot be resolved from written docs.
+   - Hold the affected chunk and dependents if a required engineering freeze cannot be resolved from written docs; apply **Stopping Conditions** to any independent continuation.
 
 For each authorized ready chunk:
 
@@ -81,25 +81,27 @@ For each authorized ready chunk:
    - Save or update review outcomes beside the companion plan/checklist when the run is maintaining staged workflow artifacts.
 
 6. Handle review outcome.
-   - If contract ambiguity exists, stop and identify the exact missing decision.
+   - If contract ambiguity exists, hold the affected chunk and identify the exact missing decision; apply **Stopping Conditions** before continuing other work.
    - If implementation violates the prompt or frozen contracts and the docs are clear, write a surgical follow-up prompt.
    - Send the follow-up to the same implementer sub-agent when continuity helps; spawn a new implementer if a fresh pass is safer.
    - Repeat review/follow-up until accepted, blocked, or stopped by the user.
 
 7. Validate when evidence is required.
    - Run direct validation yourself for simple build, test, or diff checks.
+   - Keep direct checks on the same stable-candidate/provenance boundary required below for delegated validation.
    - Invoke `$validator` for feature acceptance, regression, contract, UI/browser, runtime, API, device, or integration evidence when a separate validation pass would reduce risk.
-   - Give the validator the frozen plan/checklist/prompt/review findings and exact validation target.
+   - Give the validator the exact target, applicable frozen requirements, findings and evidence limits; avoid unrelated planning/history context.
    - Treat validator results as evidence for the orchestrator's acceptance decision, not as acceptance by themselves.
 
 8. Accept the chunk.
-   - Confirm required validation passed or that the user accepted the validation gap.
+   - Confirm required validation passed under the current recorded acceptance contract; handle explicit user-approved exceptions under **Commit Rules**, never as fabricated PASS evidence.
+   - Recheck that the candidate source/diff and relevant build still match the reviewed/validated identity; changes invalidate affected evidence until reconciled and revalidated.
    - Confirm no out-of-scope work remains.
    - Apply the explicit commit policy.
    - Use the chunk's proposed commit message when acceptable; otherwise write a one-line commit message with the chunk ID prefix when one exists.
 
 9. Continue.
-   - Update or report checklist, prompt-map, readiness-audit, and review-outcome state as appropriate.
+   - Update one live handoff and the chunk's current outcome; update checklist/map/readiness entries when their state/dependencies change, without copying the running journal into each artifact.
    - Choose the next ready chunk.
    - Stop when all chunks are complete, blocked, or no ready chunk remains.
 
@@ -107,7 +109,7 @@ For each authorized ready chunk:
 
 The readiness audit exists to resolve blockers before implementation, not during the first failed prompt.
 
-For every chunk, record:
+Record each chunk's ID and readiness classification. For non-ready chunks, record the applicable details below; reuse a shared blocker entry for affected chunks rather than duplicating its analysis. Dependency-only holds need the missing predecessor and acceptance link, not an options essay.
 
 - chunk ID/name
 - readiness classification: `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`
@@ -119,10 +121,12 @@ For every chunk, record:
 
 Before implementation starts, require one of:
 
-- all contract blockers and small freezes are resolved and written back into the plan/checklist/prompt map
-- or the user explicitly authorizes a ready-subset run while blocked chunks remain held
+- contract blockers are resolved and the intended chunk's required engineering freezes are recorded in authoritative artifacts
+- or the user explicitly authorizes a ready-subset run while unrelated contract-blocked chunks remain held
 
-Do not spawn implementer sub-agents for blocked chunks. Do not let the implementer resolve parent-route semantics, API contract choices, persistence semantics, timestamp timebases, ownership boundaries, cleanup semantics, or other frozen-contract decisions.
+Complete later mechanism freezes before their first dependent chunk; independent ready work need not await every later implementation detail. Investigate major feasibility/irreversible risks early. Do not spawn implementers for blocked chunks or let them decide missing parent-route, API, persistence, timebase, ownership or cleanup contracts.
+
+Bound further investigation by a question and an observation that distinguishes mechanisms. When equivalent experiments cannot resolve missing contract, access or authority, record one focused decision/blocker and continue only independently authorized ready work.
 
 ## Prompt Writing Rules
 
@@ -166,7 +170,7 @@ In the final summary, include a contract verification matrix and explicitly conf
 Keep the implementer `Read these first:` list focused:
 
 - include project instruction/context docs required by the repo
-- include the feature plan
+- include relevant feature-plan sections, not unrelated phases/history
 - include the implementation checklist only when it adds chunk-relevant boundaries or state not restated in the prompt
 - include chunk-specific docs/artifacts the implementer actually needs
 - do not include the prompt map by default
@@ -183,21 +187,35 @@ When spawning an implementer sub-agent:
 - instruct it to edit files directly if the runtime supports sub-agent code edits
 - instruct it not to commit
 - keep the task narrow and self-contained
+- where supported, use scoped context instead of a full-history fork, carrying all applicable instructions, authority and contract references; preserve model/effort choices
 - avoid delegating planner/reviewer decisions
 - wait only when the result is needed for the next critical-path step
 - close sub-agents when their chunk is accepted or permanently blocked
 
-If sub-agent edits are not visible in the main workspace after completion, stop and report the integration limitation instead of reviewing a summary as if it were a diff.
+If sub-agent edits are not inspectable as the actual candidate diff, hold that chunk and report the integration limitation instead of reviewing a summary as if it were a diff. Apply **Stopping Conditions** before continuing other work.
 
 When invoking a validator pass:
 
 - instruct it to use `$validator`
-- provide the exact expected behavior, frozen contracts, and validation target
+- provide the exact expected behavior, frozen contracts and candidate identity: baseline revision plus scoped changes (including relevant untracked inputs), and the relevant build/artifact and its source provenance
+- release implementer writes before validation; prevent overlapping writes to the validated scope, relevant harness/configuration inputs, or replacement of the tested build/target until the pass is released
 - provide approved credential or environment sources only when needed
 - ask for pass/fail/blocked evidence, residual risk, and untested areas
 - do not ask the validator to edit production code or commit
 - review the validator's evidence before accepting the chunk
 
+Use lightweight provenance sufficient to identify what was tested, such as a scoped diff/input digest and build identifier; do not require exhaustive repository/dependency hashing by default. If relevant inputs change during a pass, stop affected validation, preserve the old evidence with its limits, and establish the corrected candidate before revalidation. Non-overlapping work is safe only when it cannot alter those inputs, target or results.
+
+## Review and Validation Effort
+
+Keep roles distinct: implementer self-audit; parent actual-diff/integration/contract review; validator independent checks of assigned behavior/risks. Do not automatically add a general reviewer for each correction. Reuse a validator for bounded corrections while context remains valid; a changed mechanism, disputed finding, new risk or explicit gate may require a fresh challenge. All mandated independent reviews remain required.
+
+For corrections, put a short impact note in the existing prompt/review: changed behavior/files, affected consumers, reruns and proposed evidence reuse. Reuse only after verifying relevant source, harness, dependencies, build configuration and environment match, preserving original limits. A commit ID alone is insufficient. Rerun if applicability is uncertain; shared owners/styles may affect many consumers. Required fresh checks cannot be skipped.
+
+Use automation for repeatable regression/mechanical checks and browser inspection for relevant visual/focus behavior and discrepancies. Do not automatically repeat the full matrix with every tool. Retain each required case at its assigned evidence layer/gate. Matching builds/evidence satisfy a requirement only when it permits reuse; later platform/device checks remain pending until observed. Never silently rewrite acceptance to avoid a blocker.
+
+Report concise results, failures and evidence paths; retain raw logs/artifacts and inspect unexpected output. Link evidence instead of duplicating logs/galleries across reviews. Efficiency does not authorize model changes, missed cases, weaker contracts or unsafe rollback.
+
 ## Review Rules
 
 Review against:
@@ -256,21 +274,24 @@ For `do-not-commit`:
 - do not commit
 - report the proposed one-line commit message for each accepted chunk
 
+If the user explicitly approves a validation exception, first record its exact scope, residual risk and missing evidence as a change to the acceptance contract. It is not a PASS for the omitted check, does not waive other gates, and cannot override higher-priority safety/authority constraints. Efficiency or permission to continue working is not such an exception.
+
 Before committing:
 
 - inspect the diff
+- recheck the exact changes to be committed and relevant build against the accepted candidate identity; exclude held/unrelated work and resolve any affected evidence mismatch before committing
 - confirm the reviewed chunk is acceptable
-- confirm validation passed or that the user accepted the validation gap
+- confirm required validation passed under the current recorded acceptance contract
 - confirm no unrelated changes are included
 - use a one-line commit message
 - preserve the chunk ID prefix when one exists
 - separate sentence-like clauses with semicolons when needed
 
-Do not commit if:
+Do not commit the target chunk if:
 
 - review findings remain
 - a contract ambiguity is unresolved
-- required validation failed or could not run
+- validation required by that acceptance contract failed or could not run
 - unrelated dirty changes cannot be separated safely
 - the commit policy is `do-not-commit`
 - the commit policy is `ask-before-each-commit` and the user has not approved that specific commit
@@ -278,18 +299,18 @@ Do not commit if:
 
 ## Stopping Conditions
 
-Stop and report clearly when:
+Hold the affected chunk and its dependents, leaving them unaccepted, when:
 
-- commit authority remains unresolved after checking current instructions and still-applicable authorization
 - a contract, symbol, endpoint or data source is ambiguous, or a required output location remains unresolved after checking instructions and established conventions
 - the plan/checklist/prompt map disagree and the correct contract cannot be inferred from written docs
-- the readiness audit has unresolved `blocked-by-contract-decision` items and the user has not authorized a ready-subset run
 - a `needs-small-freeze-before-prompt` decision affects the next implementation path
 - implementation needs scope widening
-- validation cannot run and the risk cannot be resolved locally
+- required validation fails or cannot run at that chunk's assigned gate
 - sub-agent changes are not inspectable as an actual diff
-- no ready chunks remain
-- all chunks are complete
+
+Record the blocker and preserve held work/evidence. Continue independent ready work only under existing authorization and after verifying it neither depends on the held implementation nor changes the validated scope, build/test inputs or shared runtime state. Separate its acceptance and commit from held work. Different filenames alone do not establish independence; when safe separation is unproven, hold that candidate too.
+
+Stop the entire run and report when the user pauses/stops it, required run authority remains unresolved, a global safety/integrity issue prevents safe work, or no safe authorized ready chunk remains (including completion). Unresolved contract decisions still require explicit ready-subset authorization to continue unaffected work. A chunk-specific environment/validation hold alone does not cancel an otherwise authorized run; it never waives the blocked requirement.
 
 ## Final Response
 
diff --git a/plugins/staged-implementation/skills/planner/SKILL.md b/plugins/staged-implementation/skills/planner/SKILL.md
index a03f86c..e03c128 100644
--- a/plugins/staged-implementation/skills/planner/SKILL.md
+++ b/plugins/staged-implementation/skills/planner/SKILL.md
@@ -19,7 +19,7 @@ Treat questions, observations, and suggestions as analysis-only unless the user
 
 - Read the relevant plan, checklist, prompt map, surrounding code, and recent git state needed for the requested action.
 - Own design clarity, scope boundaries, staged review, and next-chunk definition.
-- Freeze contracts, invariants, schemas, routes, event semantics, error mappings, and observable behavior before implementation starts.
+- Freeze applicable contracts, invariants, schemas, routes, event semantics, error mappings, and observable behavior before their dependent implementation starts.
 - Keep chunks narrow, reviewable, and testable.
 - Review against written docs and the actual diff, not intent, summaries, or memory.
 - If a review finding exposes a real contract gap, stop treating it as implementation work and clarify the docs first.
@@ -44,6 +44,8 @@ If a path, contract, data source, diff target, or output location is required an
 
 ## Workflow
 
+Use existing artifacts when they satisfy the requested step. A scoped update or review does not require recreating the entire planning sequence.
+
 1. Prepare or read the plan.
    - Identify the design, contracts, invariants, and semantics that implementation must preserve.
    - Identify what must not be guessed during implementation.
@@ -57,9 +59,9 @@ If a path, contract, data source, diff target, or output location is required an
    - Track readiness, sequencing, dependencies, and blocked chunks.
 
 4. Run the implementation readiness audit.
-   - Inspect every chunk in the plan, checklist, and prompt map.
+   - Initially inspect every chunk in the plan, checklist and prompt map; subsequently verify changed scope and affected dependencies, broadening when shared contracts change or impact is uncertain.
    - Surface contract blockers, dependencies, environment blockers, and small decisions that should be frozen before prompting.
-   - Do not write the first implementer prompt until contract blockers are resolved or the user explicitly authorizes starting only a ready subset.
+   - Resolve blockers on the intended implementation path; unrelated contract blockers require an explicitly authorized ready-subset run. Follow the readiness rules below for later engineering freezes.
 
 5. Choose the next chunk.
    - Pick one coherent behavioral, contract, or validation unit.
@@ -83,7 +85,7 @@ If a path, contract, data source, diff target, or output location is required an
    - Do not leave important contract clarifications only in chat when docs should be updated.
 
 9. Define the next handoff.
-   - Continue only after the current chunk is accepted, corrected, or blocked on a documented ambiguity.
+   - Hand off corrections to the current chunk, or record acceptance/a documented contract, dependency or environment hold before selecting another chunk. Continue only independently authorized ready work; preserve held work and honor run-wide pauses/authority limits.
 
 ## Chunk Sizing
 
@@ -114,6 +116,16 @@ Prefer splitting work when:
 
 Do not create separate prompts just because a second file is touched, a helper is extracted, or a checklist has multiple bullets that share the same risk and validation surface.
 
+## Planning and Evidence Proportionality
+
+Give each artifact one job: plan = architecture/rationale; checklist = work/dependencies/acceptance; prompt map = assignment routing/inputs; prompt = bounded execution pass. Link authoritative contracts or restate the exact applicable subset instead of copying whole contracts into every artifact. Preserve all applicable obligations and make them accessible to a fresh worker.
+
+Design validation alongside chunk boundaries. Assign each obligation to the first gate that needs it: local implementation, integrated behavior, or actual platform/device/release. Record its target and prerequisites. Do not require later release evidence before a local chunk unless correctness or safe activation depends on it. An unavailable mandatory check remains pending at its assigned gate; emulation/local success cannot pass that gate.
+
+Prefer existing tests/harnesses and the smallest validation surface that credibly proves the contract. Expand for shared-owner impact or newly found risk. Do not prescribe every appearance × viewport × state combination, another harness or another general review without a coverage need. Retain required integration/independent review and any explicitly mandated matrix or fresh run unless expressly amended.
+
+Specify evidence reuse conditions: relevant source, harness, dependencies, configuration and environment must match, retaining original limits. Changed inputs require affected checks; uncertain applicability requires a rerun. A correction need not repeat unrelated builds/screenshots/reviews, but efficiency cannot weaken an acceptance case.
+
 ## Checklist Artifacts
 
 When asked to write or update an implementation checklist from a plan, make it operational enough for fresh implementer sessions. Include, as applicable:
@@ -124,7 +136,7 @@ When asked to write or update an implementation checklist from a plan, make it o
 - frozen contracts, invariants, exact fields, routes, states, event semantics, persistence formats, and error mappings
 - implementation tasks grouped by behavior or contract surface
 - exit criteria
-- validation commands or validation posture
+- validation commands/posture, acceptance level and required environment; distinguish local, integration and platform/release gates
 - test posture: extend existing tests, add minimal local tests, or no new test harness
 - ambiguity/blocker notes with the exact missing decision
 
@@ -148,7 +160,7 @@ Use the prompt map to preserve sequencing for the planner/reviewer. Do not inclu
 
 ## Readiness / Ambiguity Audit
 
-After the plan, implementation checklist, and prompt map exist, proactively audit all chunks before writing the first implementer prompt or starting orchestration. Do this even if the user asks generally whether implementation can begin.
+After the plan, checklist and prompt map exist, audit all chunks once before the first implementer prompt or orchestration, including major feasibility risks and environment availability. Reuse a current audit; subsequently inspect changes and affected dependencies instead of repeating the entire audit. Broaden when a shared contract changes or the affected scope cannot be established.
 
 Classify every chunk as one of:
 
@@ -167,12 +179,16 @@ For every non-ready or weakly-ready chunk, produce a decision ledger entry with:
 - options and tradeoffs when the user must decide
 - plan/checklist/prompt-map updates required after the decision
 
+One shared blocker can name all affected chunks. Dependency-only holds need the missing predecessor and acceptance link, not a repeated options/decision essay.
+
 Before implementation starts, require one of these outcomes:
 
-- all contract blockers and small freezes are resolved and written back into the plan/checklist/prompt map
-- or the user explicitly authorizes starting only the `ready` subset while blocked chunks remain held
+- contract blockers are resolved and the intended chunk's required engineering freezes are written into the authoritative artifacts
+- or the user explicitly authorizes starting only the `ready` subset while unrelated contract-blocked chunks remain held
 
-Do not treat dependency-pending chunks as contract-ambiguous unless a missing decision blocks their future prompt. Do not hide blockers inside the prompt map only; summarize them clearly for the user.
+Schedule later mechanism freezes before their first dependent chunk, using actual predecessor code. Incomplete later implementation detail need not block independent ready work; investigate architectural feasibility and irreversible migration risks early. Never relabel an unresolved product/API contract as a routine engineering choice to bypass approval.
+
+Do not treat dependency-pending chunks as contract-ambiguous unless a missing decision blocks their future prompt. Summarize actual blockers clearly. Each further experiment should identify the question and an observation that distinguishes mechanisms. If equivalent experiments cannot resolve it, report the blocker/decision and continue only independently authorized ready work.
 
 ## Implementer Prompt Rules
 
@@ -181,15 +197,15 @@ Before writing the prompt:
 - verify the correct next chunk from the checklist, prompt map, recent git history, and current worktree state when available
 - use `git status --short` and relevant `git log --oneline` checks before claiming a chunk is next, landed, or ready for review
 - state which chunk you chose and why
-- verify the readiness audit is complete, or complete it first
-- do not write the first implementer prompt if unresolved `blocked-by-contract-decision` or `needs-small-freeze-before-prompt` items affect the intended implementation path, unless the user explicitly authorized a ready-subset run
+- verify readiness covers the intended chunk and current dependencies; update affected entries, or complete the initial audit if missing
+- do not write an execution prompt for a chunk affected by unresolved `blocked-by-contract-decision` or `needs-small-freeze-before-prompt` items; ready-subset authorization permits only unaffected ready chunks
 - stop if an ambiguity blocks an implementer-quality prompt
 - include current-state context only to the extent needed for the implementer to execute the chunk without relying on prior chat memory
 
 Keep the implementer `Read these first:` list focused:
 
 - include project instruction/context docs required by the repo
-- include the feature plan
+- include relevant feature-plan sections, not unrelated phases/history
 - include the implementation checklist only when it adds chunk-relevant boundaries or state not restated in the prompt
 - include chunk-specific docs/artifacts the implementer actually needs
 - do not include the prompt map by default; it is mainly a planner/reviewer sequencing artifact
@@ -308,6 +324,8 @@ A review outcome should capture:
 - validation status and residual risk
 - next recommended action
 
+Maintain one current outcome per chunk and one live execution handoff. Link raw evidence and distinct reviewer verdicts instead of duplicating their narratives across plan/checklist/map. Preserve historical failures; update scheduling artifacts when contracts or dependency state change, not after every tool call.
+
 ## Review Rules
 
 When asked to review staged work:
diff --git a/plugins/staged-implementation/skills/validator/SKILL.md b/plugins/staged-implementation/skills/validator/SKILL.md
index fc963a9..bb43dca 100644
--- a/plugins/staged-implementation/skills/validator/SKILL.md
+++ b/plugins/staged-implementation/skills/validator/SKILL.md
@@ -45,12 +45,15 @@ Support these modes:
 
 Choose the lightest validation surface that proves the requested behavior with credible evidence.
 
+Follow the assigned acceptance level: local implementation, integration, or actual platform/device/release. Do not import later gate requirements into local acceptance unless the contract makes them prerequisites. Conversely, local or emulated evidence cannot pass an actual-platform gate; report missing mandatory evidence as pending/blocked at the proper level.
+
 ## Workflow
 
 1. Read context.
    - Read project instructions first.
-   - Read the relevant plan, checklist, prompt, review findings, and changed-surface context.
+   - Read the assigned requirements, relevant plan/checklist sections, prompt, findings and changed-surface context; expand when dependencies or applicability are unclear, not to repeat unrelated planning audits.
    - Identify the exact behavior and contracts to validate.
+   - Verify the candidate's baseline/scoped changes, relevant test/build inputs and build/artifact provenance. Confirm writes to that scope and replacement of the target are held for the pass; do not assume a URL or HEAD alone identifies what is being tested.
 
 2. Create a validation plan.
    - List the validation items.
@@ -67,17 +70,20 @@ Choose the lightest validation surface that proves the requested behavior with c
 
 4. Capture evidence.
    - Record commands or tools used.
-   - Summarize relevant output.
+   - Summarize results/failures and artifact paths; retain full logs and inspect unexpected output. Distinguish newly run checks from verified reused evidence with its original limitations.
    - Capture screenshots only when they support the verdict.
    - Note relevant console errors, network failures, logs, or API responses.
    - Do not print secrets, tokens, passwords, or sensitive env values.
 
 5. Report verdict.
+   - Recheck candidate identity before reporting. If relevant inputs changed during validation, stop the affected checks, notify the parent and qualify old evidence; do not claim it validates the changed candidate. Resume affected validation only after a stable candidate is established.
    - Mark each validation item as pass, fail, blocked, or not tested.
    - Explain failures with concrete observed behavior.
    - State residual risk and untested areas.
    - Do not claim acceptance beyond what was validated.
 
+For a correction/revalidation, independently verify the change's impact and reuse only permitted evidence whose relevant source, harness, dependencies, build configuration and environment still match. Do not trust the implementer's PASS alone. Rerun affected checks, new failure cases and explicitly required fresh checks; rerun when applicability is uncertain. Preserve original failed evidence and avoid recreating unchanged reports/galleries. Shared-owner changes may require broader coverage.
+
 ## Browser/UI Validation
 
 When validating a UI with browser or Playwright tools:
@@ -93,6 +99,8 @@ When validating a UI with browser or Playwright tools:
 - Prefer stable selectors and accessible roles when interacting with UI.
 - Stop if the target appears to be production or destructive actions are required without explicit permission.
 
+Give automation and browser inspection complementary roles instead of repeating every assertion through each tool. Capture representative affected visual/state cases plus identified regressions; retain any explicitly mandated viewport/state matrix. Broaden for a concrete uncovered risk, not merely because another tool or reviewer is available.
+
 ## Contract Validation
 
 When validating contracts, check the exact specified behavior: