[P1] Add verified execution, repair, and next-slice continuation workflow #431

New issue

Closed

opened 2026-09-10 21:18:06 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-10 21:18:06 +00:00

Owner

Goal

Implement the runtime child slice of #68 after normalized TaskIR and resolved context exist: execute a standalone task through existing Prolog-RLM primitives, treat observable verification as the completion boundary, repair from structured failures, and generate the next coherent slice from the resulting canonical state.

Required workflow

Model the loop semantically as:

resolved context
      |
      v
normalized TaskIR
      |
      v
model-targeted execution prompt
      |
      v
supervised worker / graph execution
      |
      v
independent observations + verification
      |
   +--+--+
   |     |
 reject  accept
   |       |
repair     v
   |   re-resolve canonical state
   +       |
           v
    compile next coherent slice

The worker may revise its plan as observations change. It may not silently weaken host/operator hard invariants or the frozen acceptance gates for the current run.

Build on existing runtime

Use rlm_graph as the workflow state machine rather than adding a new scheduler. Use rlm_artifact for immutable TaskIR/context/evidence/prompt/continuation artifacts and fresh-root handoff. Use rlm_agent for supervised child execution. Use existing completion/tool/MCP/authority/trace/future contracts.

Compose with:

#54 async-first execution;
#56 proof/evidence result acceptance when landed/applicable;
#57 effect identity and once-only observation semantics;
existing graph checkpoint/resume and cancellation;
existing artifact version/provenance semantics.

Public APIs

Add host-facing APIs equivalent in semantics to:

workflow_compile(+TaskIR, +ResolvedContext, +Options, -Outcome).
workflow_run_async(+CompiledWorkflow, +Options, -Future).
workflow_run(+CompiledWorkflow, +Options, -Outcome).
workflow_resume_async(+WorkflowRef, +Resume, +Options, -Future).
workflow_resume(+WorkflowRef, +Resume, +Options, -Outcome).
workflow_status(+WorkflowRef, -Outcome).
workflow_evidence(+WorkflowRef, -Outcome).
workflow_next_slice(+WorkflowRef, +Options, -Outcome).

workflow_run/3 must await the same canonical async execution path as workflow_run_async/3.

Exact naming may be refined to match repository conventions.

Verification semantics

Observable gates may include tests, CI/CD status, static validators, repository state assertions, review-thread state, formal/symbolic verifiers, or other host-configured evidence.

Requirements:

worker self-report does not satisfy an observable external gate;
missing, skipped, cancelled, pending, or failed required checks are not success;
failure evidence is retained and inspectable;
repair attempts target the actual failed gate/root cause and rerun the relevant acceptance path;
a weaker substitute check cannot silently replace a required failing verifier;
acceptance and worker completion remain distinct events.

Continuation semantics

After acceptance:

re-resolve the actual resulting canonical state;
determine the smallest coherent next slice that advances the remaining goal without duplicating completed work;
normalize that slice into a new versioned TaskIR;
render a fresh standalone prompt/workflow artifact;
preserve lineage from prior slice -> evidence -> accepted state -> next slice.

The next slice must not blindly inherit stale SHAs, PR states, TODOs, or implementation assumptions from the prior prompt.

Steering and fresh roots

A host/operator may steer a running workflow by adding/versioning preference or requirement input according to authority policy. Fresh model roots should receive bounded current artifacts rather than the full prior conversation transcript.

Acceptance

Workflow is implemented as composition over existing graph/agent/artifact primitives, not a parallel orchestration engine.
Sync and async run/resume surfaces are equivalent and use one canonical execution path.
A worker may revise strategy without mutating frozen hard acceptance criteria in place.
Worker completion and acceptance are separately traceable.
A required failing/pending/missing verifier prevents acceptance.
Structured repair can loop back and rerun verification under hard step/visit/time/budget limits.
Accepted state is re-resolved before continuation compilation.
workflow_next_slice/... produces a versioned standalone continuation task/prompt grounded in the new canonical state.
Artifact lineage/provenance links requirements, context, execution prompt, observations, verification, accepted result, and continuation.
Deterministic fixtures cover pass, fail->repair->pass, verifier error/timeout, cancellation, restart/resume, stale prior-state correction, and no-next-slice completion.

Refs #68 #69 #70 #54 #56 #57

## Goal Implement the runtime child slice of #68 after normalized TaskIR and resolved context exist: execute a standalone task through existing Prolog-RLM primitives, treat observable verification as the completion boundary, repair from structured failures, and generate the next coherent slice from the resulting canonical state. ## Required workflow Model the loop semantically as: ```text resolved context | v normalized TaskIR | v model-targeted execution prompt | v supervised worker / graph execution | v independent observations + verification | +--+--+ | | reject accept | | repair v | re-resolve canonical state + | v compile next coherent slice ``` The worker may revise its plan as observations change. It may not silently weaken host/operator hard invariants or the frozen acceptance gates for the current run. ## Build on existing runtime Use `rlm_graph` as the workflow state machine rather than adding a new scheduler. Use `rlm_artifact` for immutable TaskIR/context/evidence/prompt/continuation artifacts and fresh-root handoff. Use `rlm_agent` for supervised child execution. Use existing completion/tool/MCP/authority/trace/future contracts. Compose with: - #54 async-first execution; - #56 proof/evidence result acceptance when landed/applicable; - #57 effect identity and once-only observation semantics; - existing graph checkpoint/resume and cancellation; - existing artifact version/provenance semantics. ## Public APIs Add host-facing APIs equivalent in semantics to: ```prolog workflow_compile(+TaskIR, +ResolvedContext, +Options, -Outcome). workflow_run_async(+CompiledWorkflow, +Options, -Future). workflow_run(+CompiledWorkflow, +Options, -Outcome). workflow_resume_async(+WorkflowRef, +Resume, +Options, -Future). workflow_resume(+WorkflowRef, +Resume, +Options, -Outcome). workflow_status(+WorkflowRef, -Outcome). workflow_evidence(+WorkflowRef, -Outcome). workflow_next_slice(+WorkflowRef, +Options, -Outcome). ``` `workflow_run/3` must await the same canonical async execution path as `workflow_run_async/3`. Exact naming may be refined to match repository conventions. ## Verification semantics Observable gates may include tests, CI/CD status, static validators, repository state assertions, review-thread state, formal/symbolic verifiers, or other host-configured evidence. Requirements: - worker self-report does not satisfy an observable external gate; - missing, skipped, cancelled, pending, or failed required checks are not success; - failure evidence is retained and inspectable; - repair attempts target the actual failed gate/root cause and rerun the relevant acceptance path; - a weaker substitute check cannot silently replace a required failing verifier; - acceptance and worker completion remain distinct events. ## Continuation semantics After acceptance: 1. re-resolve the actual resulting canonical state; 2. determine the smallest coherent next slice that advances the remaining goal without duplicating completed work; 3. normalize that slice into a new versioned TaskIR; 4. render a fresh standalone prompt/workflow artifact; 5. preserve lineage from prior slice -> evidence -> accepted state -> next slice. The next slice must not blindly inherit stale SHAs, PR states, TODOs, or implementation assumptions from the prior prompt. ## Steering and fresh roots A host/operator may steer a running workflow by adding/versioning preference or requirement input according to authority policy. Fresh model roots should receive bounded current artifacts rather than the full prior conversation transcript. ## Acceptance - [ ] Workflow is implemented as composition over existing graph/agent/artifact primitives, not a parallel orchestration engine. - [ ] Sync and async run/resume surfaces are equivalent and use one canonical execution path. - [ ] A worker may revise strategy without mutating frozen hard acceptance criteria in place. - [ ] Worker completion and acceptance are separately traceable. - [ ] A required failing/pending/missing verifier prevents acceptance. - [ ] Structured repair can loop back and rerun verification under hard step/visit/time/budget limits. - [ ] Accepted state is re-resolved before continuation compilation. - [ ] `workflow_next_slice/...` produces a versioned standalone continuation task/prompt grounded in the new canonical state. - [ ] Artifact lineage/provenance links requirements, context, execution prompt, observations, verification, accepted result, and continuation. - [ ] Deterministic fixtures cover pass, fail->repair->pass, verifier error/timeout, cancellation, restart/resume, stale prior-state correction, and no-next-slice completion. Refs #68 #69 #70 #54 #56 #57

nsaspy commented

2026-09-10 21:23:31 +00:00

Author

Owner

Duplicate of #71 (pre-existing Forgejo mirror with GitHub number parity). Closing this accidental duplicate created by today's open-state sync; #71 stays canonical on Forgejo.

nsaspy closed this issue

2026-09-10 21:23:31 +00:00