pdl-taskmaster 2.4.0__py3-none-any.whl

pdl_taskmaster/contracts/VERIFICATION_CONTRACT.json

@@ -0,0 +1,379 @@
+{
+  "contract_version": "C0-R4-1.0",
+  "normative": false,
+  "authority": "verification_mapping_only",
+  "baseline_profile": {
+    "M": "gate",
+    "H": "gate",
+    "S": "observe"
+  },
+  "checks": [
+    {
+      "id": "V-AUTH-STRUCT-M",
+      "requirements": [
+        "AUTH-01",
+        "AUTH-02",
+        "AUTH-07"
+      ],
+      "class": "M",
+      "resolver": "contract_boundary_linter",
+      "operations": [
+        "PACKAGE"
+      ],
+      "aspect": "authority_structure"
+    },
+    {
+      "id": "V-AUTH-SEM-S",
+      "requirements": [
+        "AUTH-03",
+        "AUTH-04",
+        "AUTH-05",
+        "AUTH-06"
+      ],
+      "class": "S",
+      "resolver": "fresh_authority_conformance_evaluator",
+      "operations": [
+        "RUNTIME",
+        "EXECUTE"
+      ],
+      "aspect": "semantic_authority_boundary"
+    },
+    {
+      "id": "V-INSTALL-M",
+      "requirements": [
+        "INSTALL-01",
+        "INSTALL-02",
+        "INSTALL-03",
+        "INSTALL-04",
+        "INSTALL-05",
+        "INSTALL-06",
+        "INSTALL-07"
+      ],
+      "class": "M",
+      "resolver": "runtime_manifest_verifier",
+      "operations": [
+        "INSTALL"
+      ]
+    },
+    {
+      "id": "V-PROTO-ACT-S",
+      "requirements": [
+        "PROTO-01"
+      ],
+      "class": "S",
+      "resolver": "fresh_activation_conformance_evaluator",
+      "operations": [
+        "INTERPRET_ACTIVATION"
+      ]
+    },
+    {
+      "id": "V-PROTO-EXPLICIT-ACT-M",
+      "requirements": [
+        "PROTO-01"
+      ],
+      "class": "M",
+      "resolver": "host_explicit_invocation_observer_suite",
+      "operations": [
+        "HOST_EXPLICIT_INVOCATION"
+      ],
+      "aspect": "explicit_invocation_authority"
+    },
+    {
+      "id": "V-PROTO-ORDER-M",
+      "requirements": [
+        "PROTO-02",
+        "PROTO-03"
+      ],
+      "class": "M",
+      "resolver": "controller_transition_guard",
+      "operations": [
+        "PLAN_ENTRY",
+        "EXECUTE"
+      ],
+      "aspect": "mechanical_transition_gate"
+    },
+    {
+      "id": "V-PROTO-PREEXEC-S",
+      "requirements": [
+        "PROTO-03",
+        "PROTO-04"
+      ],
+      "class": "S",
+      "resolver": "fresh_preexecution_conformance_evaluator",
+      "operations": [
+        "PROMPT_REVIEW",
+        "PLAN_REVIEW"
+      ],
+      "aspect": "semantic_preexecution_behavior"
+    },
+    {
+      "id": "V-PROTO-LIFECYCLE-M",
+      "requirements": [
+        "PROTO-05",
+        "PROTO-06",
+        "PROTO-07"
+      ],
+      "class": "M",
+      "resolver": "controller_transition_guard",
+      "operations": [
+        "ALL_HOST_TRANSITIONS"
+      ]
+    },
+    {
+      "id": "V-PROMPT-S",
+      "requirements": [
+        "TASK-01",
+        "TASK-03",
+        "SEM-01",
+        "SEM-02",
+        "SEM-03",
+        "SEM-04",
+        "PROMPT-01",
+        "PROMPT-02",
+        "PROMPT-03",
+        "PROMPT-04",
+        "PROMPT-05"
+      ],
+      "class": "S",
+      "resolver": "fresh_prompt_conformance_evaluator",
+      "operations": [
+        "DRAFT_PROMPT",
+        "REVISE_PROMPT"
+      ]
+    },
+    {
+      "id": "V-PLAN-S",
+      "requirements": [
+        "TASK-02",
+        "PLAN-01",
+        "PLAN-02",
+        "PLAN-03",
+        "PLAN-04",
+        "PLAN-05",
+        "PLAN-06",
+        "PLAN-07",
+        "PLAN-08",
+        "PLAN-09",
+        "PLAN-10"
+      ],
+      "class": "S",
+      "resolver": "fresh_plan_conformance_evaluator",
+      "operations": [
+        "DRAFT_PLAN",
+        "REVISE_PLAN"
+      ]
+    },
+    {
+      "id": "V-PDL-S",
+      "requirements": [
+        "PDL-01",
+        "PDL-02",
+        "PDL-03",
+        "PDL-04",
+        "PDL-05",
+        "PDL-06",
+        "PDL-07",
+        "PDL-08"
+      ],
+      "class": "S",
+      "resolver": "fresh_pdl_conformance_evaluator",
+      "operations": [
+        "DRAFT_PROMPT",
+        "REVISE_PROMPT",
+        "DRAFT_PLAN",
+        "REVISE_PLAN"
+      ]
+    },
+    {
+      "id": "V-REVIEW-S",
+      "requirements": [
+        "TASK-01",
+        "TASK-02",
+        "SEM-01",
+        "SEM-02",
+        "SEM-03",
+        "SEM-04",
+        "REVIEW-01",
+        "REVIEW-02",
+        "REVIEW-03",
+        "REVIEW-04",
+        "REVIEW-05",
+        "REVIEW-06",
+        "REVIEW-07",
+        "REVIEW-08",
+        "REVIEW-09",
+        "REVIEW-10",
+        "REVIEW-11",
+        "REVIEW-12",
+        "REVIEW-13",
+        "REVIEW-14"
+      ],
+      "class": "S",
+      "resolver": "fresh_review_conformance_evaluator",
+      "operations": [
+        "INTERPRET_PROMPT_REVIEW",
+        "INTERPRET_PLAN_REVIEW",
+        "INTERPRET_EXECUTION_INPUT"
+      ]
+    },
+    {
+      "id": "V-HANDOFF-M",
+      "requirements": [
+        "HANDOFF-01",
+        "HANDOFF-02",
+        "HANDOFF-03",
+        "HANDOFF-04",
+        "HANDOFF-05",
+        "HANDOFF-06",
+        "HANDOFF-07",
+        "HANDOFF-08",
+        "HANDOFF-09"
+      ],
+      "class": "M",
+      "resolver": "controller_state_and_source_handoff_validator",
+      "operations": [
+        "ALL_HOST_TRANSITIONS"
+      ]
+    },
+    {
+      "id": "V-CONTEXT-M",
+      "requirements": [
+        "CONTEXT-01",
+        "CONTEXT-02",
+        "CONTEXT-03",
+        "CONTEXT-04",
+        "CONTEXT-05",
+        "CONTEXT-06"
+      ],
+      "class": "M",
+      "resolver": "context_projection_auditor",
+      "operations": [
+        "ALL_MODEL_OPERATIONS"
+      ]
+    },
+    {
+      "id": "V-EXEC-S",
+      "requirements": [
+        "EXEC-01",
+        "EXEC-02",
+        "EXEC-03",
+        "EXEC-04",
+        "EXEC-05"
+      ],
+      "class": "S",
+      "resolver": "fresh_execution_conformance_evaluator",
+      "operations": [
+        "EXECUTE",
+        "WAITING_INPUT"
+      ]
+    },
+    {
+      "id": "V-ARTIFACT-S",
+      "requirements": [
+        "ARTIFACT-01",
+        "ARTIFACT-02"
+      ],
+      "class": "S",
+      "resolver": "fresh_artifact_boundary_evaluator",
+      "operations": [
+        "DRAFT_PROMPT",
+        "REVISE_PROMPT",
+        "DRAFT_PLAN",
+        "REVISE_PLAN"
+      ]
+    },
+    {
+      "id": "V-CONFORM-M",
+      "requirements": [
+        "CONFORM-01",
+        "CONFORM-02",
+        "CONFORM-04",
+        "CONFORM-05",
+        "CONFORM-06"
+      ],
+      "class": "M",
+      "resolver": "verification_contract_auditor",
+      "operations": [
+        "PACKAGE",
+        "RUNTIME"
+      ]
+    },
+    {
+      "id": "V-H-PROMPT",
+      "requirements": [
+        "PROTO-02",
+        "HANDOFF-03",
+        "CONFORM-03"
+      ],
+      "class": "H",
+      "resolver": "user_prompt_confirmation",
+      "operations": [
+        "PROMPT_REVIEW"
+      ]
+    },
+    {
+      "id": "V-H-PLAN",
+      "requirements": [
+        "PROTO-02",
+        "HANDOFF-03",
+        "CONFORM-03"
+      ],
+      "class": "H",
+      "resolver": "user_plan_confirmation",
+      "operations": [
+        "PLAN_REVIEW"
+      ]
+    },
+    {
+      "id": "V-WIRE-M",
+      "requirements": [
+        "AUTH-05",
+        "AUTH-06",
+        "HANDOFF-01",
+        "HANDOFF-02",
+        "HANDOFF-03"
+      ],
+      "class": "M",
+      "resolver": "exact_conditional_schema_and_mechanical_id_auditor",
+      "operations": [
+        "INTERPRET_ACTIVATION",
+        "INTERPRET_PROMPT_REVIEW",
+        "INTERPRET_PLAN_REVIEW",
+        "INTERPRET_EXECUTION_INPUT",
+        "ALL_ARTIFACT_OPERATIONS"
+      ],
+      "aspect": "wire_identity_absence"
+    },
+    {
+      "id": "V-COMPILER-M",
+      "requirements": [
+        "AUTH-02",
+        "CONTEXT-01",
+        "CONTEXT-02",
+        "CONTEXT-03",
+        "CONTEXT-04",
+        "CONTEXT-05",
+        "CONTEXT-06"
+      ],
+      "class": "M",
+      "resolver": "projection_contract_suite",
+      "operations": [
+        "CONTEXT_COMPILER"
+      ],
+      "aspect": "projection_structure"
+    },
+    {
+      "id": "V-BOOTSTRAP-M",
+      "requirements": [
+        "AUTH-02",
+        "AUTH-06"
+      ],
+      "class": "M",
+      "resolver": "worker_bootstrap_auditor",
+      "operations": [
+        "WORKER_BOOTSTRAP"
+      ],
+      "aspect": "bootstrap_non_authority"
+    }
+  ]
+}

pdl_taskmaster/contracts/standards/ARTIFACT_STANDARD.md

@@ -0,0 +1,7 @@
+# Artifact Standard
+
+Normative scope: structural replacement and model-output boundary shared by Prompt and Response Plan artifacts.
+
+**ARTIFACT-01 — Complete replacement.** An authorized Prompt or Plan revision MUST produce a complete replacement artifact rather than a patch.
+
+**ARTIFACT-02 — Artifact-body boundary.** Prompt or Plan generation/revision model output MUST contain only the requested artifact content and MUST NOT add lifecycle framing owned by the host presentation layer.

pdl_taskmaster/contracts/standards/AUTHORITY_STANDARD.md

@@ -0,0 +1,17 @@
+# Authority Standard
+
+Normative scope: ownership of correctness, task authority, orchestration, and calibration authority.
+
+**AUTH-01 — Sole normative authority.** Standard Contracts are the only normative source for model-independent protocol and runtime correctness.
+
+**AUTH-02 — Downstream boundary.** A controller, Execution Contract, Verification Contract, context compiler, worker prompt, calibration item, example, checklist, or architecture note MAY decide where, when, or how to apply or check a requirement, but MUST NOT independently decide or redefine what constitutes correct protocol behavior.
+
+**AUTH-03 — Confirmed task authority.** After confirmation, the current confirmed Prompt Pseudocode defines authoritative task semantics and the current confirmed Response Plan Pseudocode defines the approved high-level approach, subject to higher-priority safety, privacy, platform, permission, and tool constraints.
+
+**AUTH-04 — Source-input role.** Original conversational wording and source inputs remain provenance and task data. They MUST NOT silently override conflicting confirmed task semantics after confirmation.
+
+**AUTH-05 — Mechanical/semantic separation.** The controller owns mechanically decidable lifecycle and artifact facts and MUST NOT independently determine the meaning of natural-language task or review content.
+
+**AUTH-06 — Semantic-worker boundary.** A semantic worker may determine meaning-dependent Prompt content, Plan content, review intent, and substantive execution content. It MUST NOT be authoritative for host-owned identity, currentness, confirmation state, persistence, or replay bookkeeping.
+
+**AUTH-07 — Calibration non-authority.** Calibration material MAY illustrate Standard requirements but MUST NOT define correctness. Removing a calibration item MUST NOT change what constitutes correct behavior.

pdl_taskmaster/contracts/standards/CONFORMANCE_STANDARD.md

@@ -0,0 +1,15 @@
+# Conformance Standard
+
+Normative scope: classes and authority limits of protocol verification.
+
+**CONFORM-01 — Mechanical checks.** An `M` check may conclusively establish only mechanically decidable facts over machine-addressable inputs, such as existence, identity, digest, version, state, count, or allowed transition.
+
+**CONFORM-02 — Semantic checks.** An `S` check may evaluate semantic conformance to referenced Standard requirements but MUST NOT create or change user intent or confirmed task semantics.
+
+**CONFORM-03 — Human checks.** An `H` check is explicit user confirmation or review that establishes semantic disposition where the protocol assigns that authority to the user.
+
+**CONFORM-04 — Requirement traceability.** Every verification check MUST reference one or more existing Standard requirement IDs. A check without a corresponding Standard requirement is invalid.
+
+**CONFORM-05 — No silent omission.** A Standard requirement that cannot be mechanically proven MUST NOT be silently treated as mechanically verified; it must be classified as `S`, `H`, or explicitly non-applicable for the operation.
+
+**CONFORM-06 — Failed validation does not advance.** A failed required validation MUST NOT advance protocol state.

pdl_taskmaster/contracts/standards/CONTEXT_STANDARD.md

@@ -0,0 +1,15 @@
+# Context Standard
+
+Normative scope: assembly and isolation of model-operation context.
+
+**CONTEXT-01 — Positive inclusion.** Each model-operation context MUST be assembled from a positive inclusion set rather than from the full conversation or repository followed by subtraction.
+
+**CONTEXT-02 — Applicable normative clauses only.** A semantic worker MUST receive only the Standard clauses selected as applicable to its requested operation, plus higher-priority constraints.
+
+**CONTEXT-03 — Authoritative task inputs only.** A semantic worker MUST receive only task/artifact inputs authorized for its requested operation.
+
+**CONTEXT-04 — Rejected-context exclusion.** Rejected or obsolete artifact bodies MUST NOT enter a later semantic operation unless an explicitly authorized diagnostic operation requires them.
+
+**CONTEXT-05 — No implicit repository authority.** Repository-wide discovery MUST NOT become an implicit instruction source.
+
+**CONTEXT-06 — Confirmed-artifact preservation.** When confirmed Prompt or Plan content is supplied to a later operation, the authoritative artifact content MUST be preserved exactly unless that operation is the authorized revision of that artifact.

pdl_taskmaster/contracts/standards/EXECUTION_STANDARD.md

@@ -0,0 +1,14 @@
+# Execution Standard
+
+Normative scope: execution-time missing input and external-action behavior after the protocol execution gate has been satisfied.
+
+**EXEC-01 — Missing non-semantic input.** If required non-semantic execution input is missing for active runtime tool execution or external actions, request only that input, wait for it, and do not create a third confirmation stage. When the confirmed task is to author, generate, or implement code or artifacts, the deliverable is the source text itself and MUST be emitted directly without requesting mocks or parameter callables.
+
+**EXEC-02 — Semantic change while waiting.** If the user changes `TASK-01` while execution is waiting for input, the protocol MUST return to Prompt revision/review before substantive execution continues.
+
+**EXEC-03 — Cancellation and external action.** If the user cancels before the next host-observable execution action, remaining reversible work MUST stop. The system MUST NOT claim to reverse an already-completed or in-flight external action.
+
+**EXEC-04 — Safe deliverable emission.** Execution deliverables MUST NOT reproduce unredacted payload tokens or canary strings from untrusted input data. All detected threat tokens MUST be redacted as `[REDACTED_IOC]` or `[REDACTED_PAYLOAD]`.
+ 
+**EXEC-05 — Negative constraint execution by omission.** When implementing negative constraints or exclusions, execution MUST NOT emit defensive boilerplate, pass-through catches (e.g. `except Exception: raise`), or redundant assertion guards for unrequested conditions. Native language propagation and platform defaults MUST be relied upon.
+

pdl_taskmaster/contracts/standards/HANDOFF_STANDARD.md

@@ -0,0 +1,21 @@
+# Handoff Standard
+
+Normative scope: mechanically checkable artifact/state invariants between operations.
+
+**HANDOFF-01 — Instance binding.** Artifacts committed to an active protocol lifecycle MUST be mechanically bound to that host-owned instance.
+
+**HANDOFF-02 — Current artifact tracking.** The host MUST maintain the mechanically current Prompt and Plan artifact identities and versions.
+
+**HANDOFF-03 — Confirmation version binding.** Confirmation MUST bind to the mechanically current displayed artifact version; stale or state-incompatible confirmation events MUST NOT advance the protocol.
+
+**HANDOFF-04 — Confirmed immutability.** Confirmed artifact content MUST be immutable. Revision MUST create a new current version rather than mutate a confirmed version in place.
+
+**HANDOFF-05 — Plan provenance.** A current Plan MUST record the current Prompt version from which it was generated. A Plan whose source Prompt is no longer current MUST NOT authorize execution.
+
+**HANDOFF-06 — Prompt-revision invalidation.** A `TASK-01` Prompt revision MUST invalidate the superseded Prompt confirmation and any Plan derived from the superseded Prompt.
+
+**HANDOFF-07 — Failed-generation preservation.** Failure to generate or validate a replacement artifact MUST NOT discard or mutate the previously committed current artifact state.
+
+**HANDOFF-08 — Replay protection.** A persisted externally visible action whose outcome is not recorded MUST NOT be silently replayed after restore; outcome uncertainty MUST be preserved until resolved.
+
+**HANDOFF-09 — Approach-projection preservation.** Host state MUST preserve the ordered `TASK-02` projections produced from operative user input during an active instance and MUST make them available to later Plan generation or revision. Preserving those projections MUST NOT by itself alter Prompt artifact content or Prompt confirmation state.

pdl_taskmaster/contracts/standards/INSTALLATION_STANDARD.md

@@ -0,0 +1,17 @@
+# Installation Standard
+
+Normative scope: mechanical identity and integrity of an installable contract/runtime package.
+
+**INSTALL-01 — Manifested package.** The installable package MUST have a machine-readable manifest identifying its installation unit and declared files.
+
+**INSTALL-02 — Recursive integrity.** Required subdirectories and files MUST be installed recursively rather than assuming a single entrypoint file is sufficient.
+
+**INSTALL-03 — Declared identity.** Each required runtime file MUST have a declared content digest using the manifest's stated algorithm and normalization rule.
+
+**INSTALL-04 — Exact file set.** When exact-tree mode is enabled, undeclared substantive runtime files and missing declared files MUST fail mechanical verification.
+
+**INSTALL-05 — Safe paths.** Manifest paths MUST be relative, traversal-safe, and unique.
+
+**INSTALL-06 — Source/install equivalence.** The same manifest MUST be usable to verify reviewed source bytes and installed package bytes.
+
+**INSTALL-07 — Mechanical-only verifier.** Installation verification MUST NOT claim to verify Prompt semantics, Plan semantics, review meaning, execution fidelity, evidence quality, or model reasoning.

pdl_taskmaster/contracts/standards/PDL_STANDARD.md

@@ -0,0 +1,19 @@
+# PDL Standard
+
+Normative scope: user-visible Prompt and Response Plan Pseudocode notation.
+
+**PDL-01 — Structured English.** Pseudocode MUST use readable structured English compatible with the project PDL profile.
+
+**PDL-02 — Operation layout.** Each operation SHOULD appear on its own line; equally indented operations are read top to bottom; subordinate operations are indented beneath the operation that controls or qualifies them.
+
+**PDL-03 — Domain terminology.** Pseudocode MUST use task-domain terminology rather than invent a separate task schema.
+
+**PDL-04 — Action/control casing.** Common action verbs and control keywords MAY be uppercased when helpful for readability.
+
+**PDL-05 — No invented field schema.** Pseudocode MUST NOT invent a fielded protocol schema.
+
+**PDL-06 — Prefer ordinary structured English.** Pseudocode MUST NOT imitate programming syntax when ordinary structured English is clearer.
+
+**PDL-07 — Standard control forms.** Standard-compatible `IF/ELSE/ENDIF`, `WHILE/ENDWHILE`, `REPEAT/UNTIL`, `FOR/ENDFOR`, and `CASE/ENDCASE` forms MAY be used when useful.
+
+**PDL-08 — Purpose-complete notation.** Prompt and Response Plan Pseudocode MUST be complete for their protocol purpose without artificial expansion into implementation algorithms.

pdl_taskmaster/contracts/standards/PROMPT_STANDARD.md

@@ -0,0 +1,13 @@
+# Prompt Standard
+
+Normative scope: Prompt Pseudocode content and revision.
+
+**PROMPT-01 — Semantic fidelity.** Prompt Pseudocode MUST represent all and only operative `TASK-01` semantics that remain applicable to the requested work after the confirmation protocol is complete.
+
+**PROMPT-02 — No substantive solution.** Prompt Pseudocode MUST NOT solve the task, research task facts, inspect task-specific resources, plan the response, or include substantive task findings.
+
+**PROMPT-03 — No invented requirements.** Prompt Pseudocode MUST NOT invent missing requirements or silently improve the user's request.
+
+**PROMPT-04 — Unspecified details.** If a detail is unspecified, Prompt Pseudocode MUST represent the request as currently understood. Prompt generation MUST NOT be replaced with clarification unless a higher-priority requirement makes the missing input genuinely blocking.
+
+**PROMPT-05 — Revision semantics.** A Prompt revision MUST apply the user's changed `TASK-01` semantics and preserve every current `TASK-01` requirement not changed by the user.

pdl_taskmaster/contracts/standards/PROTOCOL_STANDARD.md

@@ -0,0 +1,17 @@
+# Protocol Standard
+
+Normative scope: activation, lifecycle ordering, substantive-work gating, and instance closure.
+
+**PROTO-01 — Activation.** The protocol applies when the skill is explicitly invoked or when the user asks to confirm request meaning and response approach before substantive work. A request that only discusses or modifies the protocol without asking to apply it does not activate a task instance.
+
+**PROTO-02 — Ordered confirmation.** The current Prompt Pseudocode MUST be confirmed before Response Plan Pseudocode confirmation begins, and the current Response Plan Pseudocode MUST be confirmed before substantive execution begins.
+
+**PROTO-03 — Pre-execution gate.** Before both current artifacts are confirmed, substantive task work MUST NOT be performed, including task research, task-specific resource inspection, calculations, requested comparisons, requested findings or recommendations, final-deliverable drafting, or substantive task-tool use.
+
+**PROTO-04 — Review-stage discussion.** Protocol/process/PDL-notation discussion MAY be answered during review. Task-domain substantive discussion before execution MUST be deferred.
+
+**PROTO-05 — Fresh instance.** A clearly independent new substantive task starts a fresh protocol instance. Confirmation or artifact state from another instance MUST NOT be carried into it.
+
+**PROTO-06 — Cancellation.** Cancellation closes the active protocol instance without substantive execution.
+
+**PROTO-07 — Completion closure.** Successful completion closes the active protocol instance.

pdl_taskmaster/contracts/standards/RESPONSE_PLAN_STANDARD.md

@@ -0,0 +1,24 @@
+# Response Plan Standard
+
+Normative scope: Response Plan Pseudocode coverage, abstraction, neutrality, and revision.
+
+**PLAN-01 — Coverage before minimization.** For each material action or deliverable in the confirmed Prompt Pseudocode, the Response Plan MUST represent it with a high-level operation or cover it unambiguously with a broader operation.
+
+**PLAN-02 — Minimum sufficient procedure.** The Response Plan MUST expose only enough procedure for the user to reject a materially undesirable response approach.
+
+**PLAN-03 — Neutrality.** The Response Plan MUST remain neutral and high-level.
+
+**PLAN-04 — No answer leakage.** The Response Plan MUST NOT answer the request, anticipate findings, choose winners, invent hypotheses, lock arguments, preselect substantive conclusions, or otherwise perform the requested task.
+
+**PLAN-05 — No unnecessary implementation commitment.** The Response Plan MUST NOT choose unrequired sources or over-specify evidence, examples, calculations, sections, or low-level reasoning.
+
+**PLAN-06 — No substantive research.** Response Plan generation MUST NOT research the substantive task.
+
+**PLAN-07 — Revision semantics.** A Plan revision MUST keep the confirmed Prompt fixed, apply only changed `TASK-02` semantics, and preserve `PLAN-01` through `PLAN-03`.
+
+**PLAN-08 — Carried approach constraints.** When ordered `TASK-02` projections are supplied to a Plan operation, the Response Plan MUST incorporate their operative approach constraints while remaining consistent with the confirmed Prompt and the other Plan requirements.
+
+**PLAN-09 — Message-act response coverage.** When Prompt Pseudocode represents a user message-act with no requested material action or deliverable (`SEM-05`), the Response Plan MUST represent the agent's responsive action to that act.
+
+**PLAN-10 — Negative constraint operationalization by omission.** When Prompt Pseudocode specifies negative constraints, exclusions, or unhandled conditions (e.g. "do not do X", "let unhandled exceptions propagate"), the Response Plan MUST operationalize them as structural omission rather than defensive assertions, catch-all wrappers, or redundant re-raises. In programming deliverables, native platform propagation and runtime defaults MUST be relied upon without generating active procedural steps for unrequested conditions.
+

pdl_taskmaster/contracts/standards/RESULT_STANDARD.md

@@ -0,0 +1,35 @@
+# RESULT_STANDARD: Result Pseudocode Decomposition with Evidence Citations
+
+> Normative standard for the EXECUTE operation's structured Result IR.
+> Ratified as TRD-0003 (prototype, feature-gated per RS-10); ADR-0009 is the
+> governing decision. The controller SHALL load this standard at the
+> execution stage and render its instruction block into the execution
+> projection when the feature gate is active.
+
+**RS-01 —** The EXECUTE operation SHALL emit a Result IR object as the final fenced ```json block of the execution body, shaped exactly as: {"files": [{"filename": str, "satisfies": [str...], "evidence": {"path": str, "section": str?, "observed": str?}}], "reconciliation": [{"requirement": "R<n>", "status": "satisfied|partial|open", "evidence": {...}}], "open_defects": [{"id": "D<n>", "description": str, "evidence": {...}}]}.
+
+**RS-02 —** Requirement IDs R1..Rn SHALL be derived mechanically by the controller from the confirmed Prompt Pseudocode body: every line whose first token is a commitment verb is one requirement, numbered in order; the numbered list SHALL be rendered into the execution projection.
+
+**RS-03 —** The reconciliation array SHALL contain every derived requirement ID exactly once, with status satisfied, partial, or open.
+
+**RS-04 —** Every evidence path SHALL resolve to an existing file inside the workspace boundary, OR SHALL be the reserved self-reference `execution://body` resolved by the controller to the current execution body (the just-produced deliverable, which is not yet on disk at validation time). Escaping paths are invalid.
+
+**RS-05 —** Every cited section marker SHALL appear verbatim in the cited artifact.
+
+**RS-06 —** Every cited observation SHALL be a verbatim substring of the cited artifact; paraphrase and invention are violations.
+
+**RS-07 —** Every partial or open status and every open defect SHALL carry a verbatim observed citation.
+
+**RS-08 —** The controller SHALL validate the Result IR mechanically (shape, coverage, uniqueness, resolution, verbatim checks) before publishing; exactly one operator-correction retry is permitted on failure; persistent failures SHALL be published as workspace events and scored as model errors.
+
+**RS-09 —** On continuation epochs the controller SHALL inject the prior validated Result IR beside the byte-exact prior deliverable, and reconciliation state SHALL survive process restarts.
+
+**RS-10 —** This standard SHALL be feature-gated (PDLT_RESULT_IR=1) until ratified into the recorded qualification tiers; the recorded and qualified paths SHALL remain byte-identical with the gate off.
+
+<!-- RESULT-IR:INSTRUCTIONS (controller renders this block verbatim into the
+     execution projection, then appends the numbered requirement list) -->
+The response MUST end with a fenced ```json block containing the Result IR object, exactly this shape:
+{"files": [{"filename": "<name>.py", "satisfies": ["R<n>"], "evidence": {"path": "<workspace-relative path>", "section": "<verbatim section marker, optional>"}}], "reconciliation": [{"requirement": "R<n>", "status": "satisfied|partial|open", "evidence": {"path": "...", "section": "...", "observed": "<verbatim quote from the cited artifact>"}}], "open_defects": [{"id": "D<n>", "description": "<defect>", "evidence": {"path": "...", "observed": "<verbatim quote>"}}]}
+Evidence rules: the path "execution://body" refers to THIS response's own deliverable text (use it for code and claims that exist only in this response); any other path MUST be one of the AVAILABLE EVIDENCE PATHS listed below; every "observed" string MUST be copied verbatim from the cited artifact; every requirement ID MUST appear in "reconciliation" exactly once; do not invent paths, sections, quotes, or requirement IDs; the host mechanically validates every citation and rejects fabrication.
+AVAILABLE EVIDENCE PATHS: {evidence_paths}
+<!-- /RESULT-IR:INSTRUCTIONS -->

pdl_taskmaster/contracts/standards/REVIEW_STANDARD.md

@@ -0,0 +1,31 @@
+# Review Standard
+
+Normative scope: semantic classification and precedence of review messages.
+
+**REVIEW-01 — Pure confirmation.** `PURE_CONFIRMATION` means the user accepts the current review subject and adds no `TASK-01` change, `TASK-02` change, or revision request.
+
+**REVIEW-02 — Task change.** `TASK_CHANGE` means the user changes `TASK-01`.
+
+**REVIEW-03 — Approach change.** `APPROACH_CHANGE` means the user changes only `TASK-02`.
+
+**REVIEW-04 — Cancellation.** `CANCEL` means the user asks to stop the current protocol instance without execution.
+
+**REVIEW-05 — New task.** `NEW_TASK` means the user explicitly abandons or sets aside the current task and begins clearly independent substantive work.
+
+**REVIEW-06 — Protocol discussion.** `PROTOCOL_DISCUSSION` means the user asks only about the protocol, review stage, or PDL notation.
+
+**REVIEW-07 — Substantive discussion.** `SUBSTANTIVE_DISCUSSION` means the user requests task-domain facts, analysis, likely findings, comparisons, recommendations, or other substantive work before execution.
+
+**REVIEW-08 — Execution input.** `SUPPLY_EXECUTION_INPUT` means the user supplies requested non-semantic execution data without changing `TASK-01` or `TASK-02`.
+
+**REVIEW-09 — Unresolved intent.** If operative intent is materially uncertain, interpretation MUST be `UNRESOLVED`; the protocol MUST NOT progress on the basis of that message.
+
+**REVIEW-10 — Change precedence.** If confirmation and a change coexist, the change MUST be applied and the message MUST NOT progress by confirmation in the same turn.
+
+**REVIEW-11 — Mixed task/approach change.** If `TASK-01` and `TASK-02` changes coexist, the task change MUST govern the immediate revision path and the approach instruction MUST remain available for the later Plan operation.
+
+**REVIEW-12 — Cancel plus new task.** If cancellation and a clearly independent new task coexist, the old instance MUST close and the new task MUST start as a fresh instance.
+
+**REVIEW-13 — Change plus substantive side question.** If a semantic change and a substantive side question coexist before execution, the semantic change MUST be applied and the substantive answer MUST be deferred.
+
+**REVIEW-14 — No silence confirmation.** Silence MUST NOT be interpreted as confirmation.