execution-policy

Execution Policy

dhpk's default execution policy for projects that adopt the harness. Read the always-visible kernel first (.cursor/rules/execution-policy-kernel.mdc), then load the conditional sections below as the selected route requires. Resource-layer markdown — referenced from the flow-guide skill and consumable directly by a project's own CLAUDE.md via the .cursor/dhpk/policies/execution-policy.md path. Not auto-loaded; opt-in.

Project overrides: projects that adopt this policy should keep their own short .claude/rules/execution-policy.md (or CLAUDE.md section) that only encodes deltas — e.g. extra sentinels, project-specific hot tables for performance reviewer, hook profile choice. Avoid copying the body wholesale; cross-link instead.

Resolution order for any reference to this file: use the project's .claude/rules/execution-policy.md first if present (it carries only deltas — extra sentinels, hot tables, hook profile), otherwise resolve to .cursor/dhpk/policies/execution-policy.md (the plugin SSOT). Projects should keep their local copy short and cross-link rather than copying the body wholesale.

Glossary (inline)

• back-stop: hook pattern did not match but the AI semantically recognises the trigger should fire → AI proactively invokes the matching reviewer (and still clears the sentinel if present).
• append-only exemption: pure additions may skip gitnexus_impact only when they add a new function/method/class, change no existing body/signature/docblock/typehint, and change no module-level state (imports or top-level constants); label the change append-only — gitnexus_impact skipped.
• reviewer dispatch: when multiple sentinels coexist, triage out false positives → dispatch the rest in parallel → code-reviewer merges/dedups (see "Reviewer dispatch").
• resumed review obligation: a session-scoped record created before reusing an existing sentinel-backed reviewer through SendMessage; it binds the final result to one generated reviewer slot, exact sentinel basename, session, dispatch, and freshness baseline.
• lifecycle clearance: reconciliation and removal of a review sentinel after its lifecycle evidence is satisfied; it is not reviewer approval or completion.
• Parallel Dispatch: two or more workers operating in one checkout under explicit, non-overlapping assigned scopes.
• Assigned Scope: the exact repo-relative file list a worker may write, diff, and verify; it is not the whole working tree and cannot be expanded by the worker.
• Worker-Owned Edit: a change within the assigned scope attributable to that worker's dispatch.
• Out-of-Scope Observation: a sibling or unrelated change outside assigned scope that the worker reports but does not modify or clean.
• Shared-State Reconciliation: the single sequential orchestrator pass that validates and updates shared ratchet/configuration state (a monotonic baseline file, e.g. a coverage or size-budget allowlist) after all parallel workers finish.
• Judgment-Dense Standardizable Batch: a bounded, repeatable implementation step touching at least three files that requires consistent content judgment but has an exact file scope and verification contract; unresolved design and unknown root cause are excluded.