execution-policy

Execution Policy

dhpk's default execution policy for projects that adopt the harness. Read the always-visible kernel first (${POLICY_BUNDLE_ROOT}/rules/execution-policy-kernel.md), then load the conditional sections below as the selected route requires. Resource-layer markdown is selected explicitly by the caller. The selected policy file has the shape <bundle-root>/rules/execution-policy.md. Resolve its real path, then derive POLICY_BUNDLE_ROOT as the real parent of that file's containing rules directory (equivalently, the file's real grandparent): the repository root for the canonical policy, or the Skill's references/execution-bundle directory for a raw Skill. Resolve required references beneath that base and fail closed with BLOCKED_RESOURCE_MISSING for missing, absolute, traversal, or symlink escaping paths. Do not infer the base from an active Skill, environment variable, checkout search, or fallback chain.

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 reviewer trigger paths, project-specific hot tables for performance reviewer, hook profile choice. Avoid copying the body wholesale; cross-link instead.

The project policy is an input delta: it may extend the selected base policy with project-specific triggers or tables, but it cannot supply a missing base resource. Keep the local copy short and cross-link rather than copying this body wholesale.

The consumer project's Project Convention supplies its branching, changelog, OpenSpec adoption, delivery, merge, and shell practices. Public Workflows follow that convention within their own authority; this portable policy does not supply a repository-specific delivery sequence.

Glossary (inline)

• reviewer trigger: a file-path/extension pattern (built-in defaults, active-module triggers, or userConfig.review_trigger_extra_paths) that identifies which reviewer role(s) apply to a diff. Trigger matching is AI judgment at dispatch time — there is no hook-armed marker file; see "Post-implementation agent gate" and the trigger table under "Reviewer dispatch."
• back-stop: a trigger pattern did not obviously match but the AI semantically recognises the review should still fire → AI proactively invokes the matching reviewer.
• 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 reviewer roles are triggered, triage out false positives → dispatch the rest in parallel → code-reviewer merges/dedups (see "Reviewer dispatch").
• applicable review wave: the one consolidated review pass for a contiguous implementation wave, covering each independent risk domain that the changed scope actually triggers.
• review evidence: an external or prior review result that identifies its scope, conclusion, supporting observations, and remaining gaps; its producer, filename, and headings do not make it sufficient by themselves.
• 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 that benefits from consistent content judgment and has an exact file scope and verification contract; unresolved design and unknown root cause are excluded. The number of files is context, not a routing threshold.
• Provider-neutral: a dispatch request that keeps Host, Provider, Model, Role, Effort, and Transport as separate fields before an adapter executes it.
• Dispatch Engine: the side-effect-free decision seam that resolves a dispatch request; adapters consume its result, and it does not own orchestration state.
• Host Profile: the active host's native Provider/Model defaults and policy settings used when no explicit Provider-scoped target is supplied.