[EPIC] Add compiler-style prompt/workflow pipeline for verified autonomous agent runs #428

New issue

Closed

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

nsaspy commented

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

Owner

Goal

Add a Prolog-native compiler-style workflow layer that turns rough operator requirements into a normalized, evidence-grounded, model-targeted execution prompt/workflow, executes it through existing RLM/agent/graph primitives, verifies completion through explicit gates, and produces the next coherent implementation slice from the resulting canonical state.

This captures an existing operator workflow rather than inventing a generic prompt-template feature.

Operator workflow to preserve

The intended pipeline is:

Start from a short or long natural-language requirement list. Treat this as source language, not as the final execution prompt.
Retrieve relevant durable/user/project memory before prompt synthesis.
Inspect relevant research repositories first. Research is an input to compilation, not optional post-hoc context.
For implementation work, inspect the target repository's live canonical state before trusting stale prompt claims: current default branch/head, applicable agent instructions, open PRs, open issues, recent commits, CI state, relevant source/tests/public APIs, and unresolved review state when available.
Discover ADRs, ADARDs, design records, specifications, architecture notes, or equivalent design authority. If an appropriate design exists, use it. Do not invent a parallel design merely because it is easier.
Reconcile conflicting/stale inputs with explicit authority precedence. Actual current source/tests/repository state outrank stale remembered behavior; dedicated research/design authority outranks tutorial prose for project-specific decisions.
Normalize the accumulated requirements into a compact intermediate representation instead of preserving the entire conversational edit history. Historical mutations such as “use X / actually use Y / X only as fallback” should compile into one current constraint.
Prefer model-native/high-density vocabulary discovered from the target model/provider or established model guidance when rendering the final prompt. This is semantic alignment, not magic trigger-word behavior.
Emit a standalone execution prompt suitable for a fresh thread/agent. The fresh execution context should receive the normalized task, authoritative context, invariants, non-goals, allowed mutations, required evidence, verification gates, and stopping conditions rather than the exploratory transcript.
Execute/steer the agent iteratively. Runtime observations may change the plan but must not silently weaken hard invariants or frozen acceptance criteria.
Use CI/CD, tests, static validation, review state, or other independently observable gates as the completion boundary. A plan-only/status-only answer is not completion when implementation was requested.
On failure, inspect structured evidence, repair the root cause, and rerun the relevant gates. Do not paper over a failing wrapper with a weaker substitute check.
After a slice is implemented and verified, inspect the new canonical state and generate the next smallest coherent standalone implementation slice. The continuation prompt must be based on the resulting repository state, not blindly copied assumptions from the prior prompt.
Preserve provenance so later roots can tell whether a fact came from operator requirements, durable memory, research, repository observation, design authority, model inference, or verifier evidence.

Architectural fit

Do not create a second scheduler, graph engine, memory store, or authority system.

Reuse:

rlm_graph for declarative bounded/resumable workflow execution;
rlm_artifact for immutable/versioned durable compiler inputs, IR, evidence, and fresh-root handoff;
rlm_agent for supervised workers and narrowing-only delegation;
rlm_chain / completion APIs for model calls;
existing structured outcomes/traces for diagnostics;
#53 authority semantics rather than inventing prompt-local authority;
#54 canonical async-first APIs;
#56 proof/evidence result acceptance where applicable;
#57 effect identity/once-only observation semantics where effectful discovery/execution is involved.

The existing research direction remains authoritative: the model chooses semantic strategy; Prolog owns execution semantics, validation, budgets, authority, tracing, persistence, and cancellation.

Child slices

#69 — normalized TaskIR and prompt compilation/rendering APIs.
#70 — evidence-backed memory/research/repository/design context resolution.
#71 — verified execution, repair, and next-slice continuation workflow.

Non-goals

No universal collection of magic trigger words.
No model-generated arbitrary Prolog callables.
No unrestricted shell/git/filesystem/network authority.
No requirement to persist private chain-of-thought.
No duplicate graph runtime, artifact database, future scheduler, or authority framework.
No assumption that one static prompt is optimal for every model/provider.

Integration acceptance

A rough requirement set can be normalized into inspectable Prolog data.
Context resolution records provenance and authority for every material input.
A model-targeted standalone execution prompt can be rendered deterministically from the normalized task plus resolved context.
Execution can run through existing bounded async/graph/agent infrastructure.
Hard acceptance criteria remain stable during a run unless the host explicitly versions/replaces them.
Verification evidence, not worker self-report, determines completion where an observable gate exists.
A verified completed slice can produce a fresh next-slice task/prompt from the new canonical state.
Deterministic tests demonstrate stale-state reconciliation, constraint normalization, design discovery, verification failure/repair, and continuation generation.

## Goal Add a Prolog-native compiler-style workflow layer that turns rough operator requirements into a normalized, evidence-grounded, model-targeted execution prompt/workflow, executes it through existing RLM/agent/graph primitives, verifies completion through explicit gates, and produces the next coherent implementation slice from the resulting canonical state. This captures an existing operator workflow rather than inventing a generic prompt-template feature. ## Operator workflow to preserve The intended pipeline is: 1. Start from a short or long natural-language requirement list. Treat this as source language, not as the final execution prompt. 2. Retrieve relevant durable/user/project memory before prompt synthesis. 3. Inspect relevant research repositories first. Research is an input to compilation, not optional post-hoc context. 4. For implementation work, inspect the target repository's live canonical state before trusting stale prompt claims: current default branch/head, applicable agent instructions, open PRs, open issues, recent commits, CI state, relevant source/tests/public APIs, and unresolved review state when available. 5. Discover ADRs, ADARDs, design records, specifications, architecture notes, or equivalent design authority. If an appropriate design exists, use it. Do not invent a parallel design merely because it is easier. 6. Reconcile conflicting/stale inputs with explicit authority precedence. Actual current source/tests/repository state outrank stale remembered behavior; dedicated research/design authority outranks tutorial prose for project-specific decisions. 7. Normalize the accumulated requirements into a compact intermediate representation instead of preserving the entire conversational edit history. Historical mutations such as “use X / actually use Y / X only as fallback” should compile into one current constraint. 8. Prefer model-native/high-density vocabulary discovered from the target model/provider or established model guidance when rendering the final prompt. This is semantic alignment, not magic trigger-word behavior. 9. Emit a standalone execution prompt suitable for a fresh thread/agent. The fresh execution context should receive the normalized task, authoritative context, invariants, non-goals, allowed mutations, required evidence, verification gates, and stopping conditions rather than the exploratory transcript. 10. Execute/steer the agent iteratively. Runtime observations may change the plan but must not silently weaken hard invariants or frozen acceptance criteria. 11. Use CI/CD, tests, static validation, review state, or other independently observable gates as the completion boundary. A plan-only/status-only answer is not completion when implementation was requested. 12. On failure, inspect structured evidence, repair the root cause, and rerun the relevant gates. Do not paper over a failing wrapper with a weaker substitute check. 13. After a slice is implemented and verified, inspect the new canonical state and generate the next smallest coherent standalone implementation slice. The continuation prompt must be based on the resulting repository state, not blindly copied assumptions from the prior prompt. 14. Preserve provenance so later roots can tell whether a fact came from operator requirements, durable memory, research, repository observation, design authority, model inference, or verifier evidence. ## Architectural fit Do not create a second scheduler, graph engine, memory store, or authority system. Reuse: - `rlm_graph` for declarative bounded/resumable workflow execution; - `rlm_artifact` for immutable/versioned durable compiler inputs, IR, evidence, and fresh-root handoff; - `rlm_agent` for supervised workers and narrowing-only delegation; - `rlm_chain` / completion APIs for model calls; - existing structured outcomes/traces for diagnostics; - #53 authority semantics rather than inventing prompt-local authority; - #54 canonical async-first APIs; - #56 proof/evidence result acceptance where applicable; - #57 effect identity/once-only observation semantics where effectful discovery/execution is involved. The existing research direction remains authoritative: the model chooses semantic strategy; Prolog owns execution semantics, validation, budgets, authority, tracing, persistence, and cancellation. ## Child slices - [ ] #69 — normalized TaskIR and prompt compilation/rendering APIs. - [ ] #70 — evidence-backed memory/research/repository/design context resolution. - [ ] #71 — verified execution, repair, and next-slice continuation workflow. ## Non-goals - No universal collection of magic trigger words. - No model-generated arbitrary Prolog callables. - No unrestricted shell/git/filesystem/network authority. - No requirement to persist private chain-of-thought. - No duplicate graph runtime, artifact database, future scheduler, or authority framework. - No assumption that one static prompt is optimal for every model/provider. ## Integration acceptance - A rough requirement set can be normalized into inspectable Prolog data. - Context resolution records provenance and authority for every material input. - A model-targeted standalone execution prompt can be rendered deterministically from the normalized task plus resolved context. - Execution can run through existing bounded async/graph/agent infrastructure. - Hard acceptance criteria remain stable during a run unless the host explicitly versions/replaces them. - Verification evidence, not worker self-report, determines completion where an observable gate exists. - A verified completed slice can produce a fresh next-slice task/prompt from the new canonical state. - Deterministic tests demonstrate stale-state reconciliation, constraint normalization, design discovery, verification failure/repair, and continuation generation.

nsaspy commented

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

Author

Owner

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

nsaspy closed this issue

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