[EPIC] Make standalone AgentProlog the flake-native prolog-rlm coding-agent frontend #1

Open
opened 2026-08-21 03:53:12 +00:00 by lost-rob0t · 7 comments
lost-rob0t commented 2026-08-21 03:53:12 +00:00 (Migrated from github.com)

Mission

Turn standalone lost-rob0t/agentProlog into the canonical downstream coding-agent product built on lost-rob0t/prolog-rlm.

Work autonomously and do as much useful work as possible per loop. Do not merely complete one trivial checklist item and stop. Before each slice, inspect current main, applicable repository instructions, docs/design, issues/comments, recent PRs/commits, source, tests, and CI; reconcile stale prose against merged executable truth.

Correct integration decision

prolog-rlm itself is NOT an AgentProlog plugin and must not be shoved through the tool-pack loader or confused with config.prolog.

prolog-rlm is the reusable runtime/library dependency. AgentProlog consumes it through a pinned Nix flake input and normal SWI-Prolog package/library loading.

Use this boundary:

AgentProlog product
  -> frontend plugins / editor clients
  -> coding/project tool packs
  -> headless coding workflow
  -> public prolog-rlm APIs
  -> prolog-rlm runtime

When to edit which repository

Edit prolog-rlm upstream when AgentProlog needs a missing or incorrect generic runtime contract, including runtime semantics, async/Futures, authority, effects, Spec/Plan/Verify, managed conversations, protocol/facade contracts, reusable project/source knowledge, MCP, tracing, or another domain-neutral primitive.

Implement downstream in AgentProlog when the behavior is coding-product-specific: concrete repository tools, Git/process/test integrations, TUI/frontend code, editor integrations, UX, product defaults, and coding workflow composition.

Use the existing external tool-pack ABI only for actual concrete tools/tool categories. rlm_tool_loader is not a general plugin loader for the runtime.

Do not treat XDG config.prolog as the package/plugin system. It is trusted runtime configuration/customization, a separate concern.

Never create parallel authority_v2, scheduler, effect ledger, verifier stack, protocol, or runtime merely to avoid an upstream change.

Dependency direction remains:

agentProlog -> prolog-rlm

Never prolog-rlm -> agentProlog.

Current repository state to reconcile

The standalone AgentProlog repository is currently sparse while substantial implementation still exists under:

lost-rob0t/prolog-rlm/agentProlog/

Audit that implementation and all supporting upstream docs/modules/tests, especially:

  • agentProlog/
  • docs/prolog-agent-roadmap.md
  • docs/prolog-agent-ui-v1.md
  • prolog_agent_ui_v1 implementation and facade
  • deterministic NDJSON fixtures
  • TUI/reference-client work
  • project tool/workflow work
  • authority/verification integration
  • protocol/reconnect/replay tests

Classify every relevant component as:

MIGRATE
REUSE VIA PROLOG-RLM API
REIMPLEMENT DOWNSTREAM
KEEP CORE
LEGACY / DO NOT MIGRATE
BLOCKED

Reference exact files/modules/functions. Migrate useful work; do not throw it away merely because it currently lives in the wrong repository.

Nix-only dependency authority

AgentProlog must be flake-native.

Create and maintain:

flake.nix
flake.lock

Expose appropriate outputs such as:

packages.${system}.agentProlog
packages.${system}.default
apps.${system}.agentProlog
apps.${system}.default
devShells.${system}.default
checks.${system}.*

Use repository conventions where names differ.

All repository-level/external dependencies must enter through Nix flake inputs or deterministic Nix packaging. Do not require:

  • git submodules;
  • ad-hoc git clone;
  • curl-piped installers;
  • runtime dependency downloads;
  • undocumented npm install, pip install, cargo install, or go install bootstrap rituals.

At minimum consume:

prolog-rlm.url = "github:lost-rob0t/prolog-rlm";

and make it follow the same nixpkgs where appropriate.

If prolog-rlm lacks suitable flake outputs, work the corresponding upstream issue rather than copying its source into AgentProlog.

Target UX:

nix run github:lost-rob0t/agentProlog
nix develop
nix flake check

Product-side plugin architecture

AgentProlog should have a small versioned plugin boundary for product-side extensions, not core runtime semantics.

Useful plugin classes include:

  • frontend/TUI renderer clients;
  • editor clients/integrations;
  • coding/project tool packs;
  • optional AgentProlog product integrations.

Loading/installing a plugin grants no capability or authority by itself.

Tool plugins

Concrete coding tools should register through the upstream external tool-library ABI (rlm_tool_loader) when that contract fits.

Candidate initial categories/tools:

filesystem: project_read, project_search, project_write, project_patch
git: git_status, git_diff, git_show, bounded git_apply
process/test: run_tests, bounded configured process_run

No ambient arbitrary shell as the easy implementation. Preserve schema validation, project-root confinement, capabilities, authority, durable effects, cancellation, budgets/timeouts, traces, and stale-preimage protection.

If the existing tool-pack ABI cannot safely express required concrete coding tools, fix the generic contract upstream rather than bypassing it.

Frontend plugins

Frontends consume the canonical prolog_agent_ui_v1 snapshot/event/command contract. They must not execute tools directly, implement authority policy, become a second scheduler, or reconstruct authoritative state from pretty logs.

Default TUI plugin

Research viable general-purpose TUI frameworks using current GitHub data and rank by stars plus maintenance, license, ecosystem maturity, async/event suitability, and Nix packaging implications.

At minimum evaluate:

  • charmbracelet/bubbletea
  • vadimdemedes/ink
  • Textualize/textual
  • ratatui/ratatui
  • anomalyco/opentui

Research snapshot when this epic was requested:

Bubble Tea   ~44.5k stars
Ink          ~39.7k
Textual      ~37.0k
Ratatui      ~22.3k
OpenTUI      ~13.1k

Refresh before implementation.

Unless current evidence exposes a material blocker, use Bubble Tea as the default installed frontend plugin. Evaluate and prefer official charmbracelet/bubbles and charmbracelet/lipgloss for common components/styling rather than reimplementing them.

Keep headless mode first-class. The TUI is only a renderer/client over the same coding workflow.

Headless coding workflow

Target one authoritative product execution path:

operator requirement
-> normalize/validate/freeze Spec
-> inspect project + instructions + current source state
-> produce/accept Plan bound to the Frozen Spec
-> execute bounded tools
-> refresh/re-index project observations
-> collect runtime/project evidence
-> Verify Frozen Spec
-> repair/replan on failure without weakening the Spec
-> structured completion with changed files, verification, usage, trace

Reuse upstream prolog-rlm components. Do not build a coding-specific generic runtime.

The same workflow must serve:

headless CLI
Bubble Tea frontend
future Emacs/Lem/other frontends

Compare old and new harnesses

Produce and maintain an explicit migration matrix:

Concern Existing nested harness Standalone target Migration action
runtime ownership
provider/model execution
async/Futures
authority
effects
Spec/Plan/Verify
project/source KB
tools
frontend protocol
UI/TUI
configuration
persistence
MCP
traces
tests
packaging

Whenever the nested harness contains product code that should live downstream, migrate/adapt it. Whenever it merely consumes or demonstrates a reusable upstream contract, depend on that contract instead of copying it.

Reuse existing work

Preserve or adapt, where applicable:

  • prolog_agent_ui_v1;
  • NDJSON transport;
  • deterministic fixture server;
  • golden protocol fixtures;
  • snapshot/event/command semantics;
  • event sequencing and reconnect/replay;
  • request correlation;
  • unknown-tool rendering;
  • approval/question/cancel flows;
  • verification, usage, trace, subagent, and effect-indeterminate presentation;
  • existing TUI interaction research/code;
  • project tool/workflow tests.

Do not fork the protocol casually merely because the renderer language changes.

Verification

Use TDD and executable evidence.

Cover at minimum:

  • protocol ordering/reconnect/duplicate suppression;
  • cancellation;
  • approval correlation;
  • unknown tools and malformed frames;
  • stale patch failure;
  • path traversal and symlink escape rejection;
  • effect replay/no duplicate mutation;
  • failed tests entering repair instead of success;
  • Frozen Spec immutability;
  • frontend crash not corrupting authoritative run state;
  • plugin ABI/version mismatch handling;
  • headless mode;
  • Bubble Tea mode;
  • clean nix build / nix run / nix flake check;
  • old/new conformance where semantically applicable.

GitHub Actions is the canonical full gate. Never weaken CI simply to make a slice green.

OLD HARNESS REMOVAL GATE

DO NOT REMOVE THE OLD HARNESS.

The current implementation under:

prolog-rlm/agentProlog/

must remain until the user explicitly gives the removal command.

You may inspect, test, migrate, adapt, deprecate, and establish compatibility coverage. Do not delete it, gut it, or replace it with an empty compatibility stub.

Create/retain a final cutover-removal issue and leave it explicitly blocked:

BLOCKED: requires explicit user authorization to remove the legacy harness.

Even when standalone parity is reached, stop before deletion.

Autonomous-loop contract

For every autonomous work cycle on this epic:

  1. search all relevant current repository state, issue/comments, recent PRs/commits, docs/design, source, tests, and applicable upstream/downstream issues;
  2. reconcile stale text against merged executable truth;
  3. choose the smallest coherent next slice;
  4. implement as much useful work as possible in that slice rather than stopping after one mechanical action;
  5. run focused tests and required gates;
  6. update docs/roadmap/issues to match reality;
  7. if more non-conflicting work in the same epic is actionable, continue rather than stopping solely because one checkbox closed;
  8. when blocked by a missing generic runtime feature, cross over to the linked prolog-rlm epic/issue instead of inventing a downstream workaround.

Deliverables

  • standalone flake-native AgentProlog;
  • pinned flake dependency on prolog-rlm;
  • migration inventory and old/new matrix;
  • product plugin contract;
  • default Bubble Tea TUI plugin;
  • reusable coding tool packs using upstream loader semantics;
  • headless coding workflow;
  • migrated/reused protocol and fixture work;
  • conformance tests;
  • docs;
  • cutover-readiness report;
  • legacy harness retained pending explicit user command.

Cross-link the companion prolog-rlm integration epic once created.

## Mission Turn standalone `lost-rob0t/agentProlog` into the canonical downstream coding-agent product built on `lost-rob0t/prolog-rlm`. Work autonomously and do as much useful work as possible per loop. Do not merely complete one trivial checklist item and stop. Before each slice, inspect current `main`, applicable repository instructions, docs/design, issues/comments, recent PRs/commits, source, tests, and CI; reconcile stale prose against merged executable truth. ## Correct integration decision `prolog-rlm` itself is **NOT** an AgentProlog plugin and must not be shoved through the tool-pack loader or confused with `config.prolog`. `prolog-rlm` is the reusable runtime/library dependency. AgentProlog consumes it through a pinned **Nix flake input** and normal SWI-Prolog package/library loading. Use this boundary: ```text AgentProlog product -> frontend plugins / editor clients -> coding/project tool packs -> headless coding workflow -> public prolog-rlm APIs -> prolog-rlm runtime ``` ### When to edit which repository **Edit `prolog-rlm` upstream** when AgentProlog needs a missing or incorrect *generic runtime contract*, including runtime semantics, async/Futures, authority, effects, Spec/Plan/Verify, managed conversations, protocol/facade contracts, reusable project/source knowledge, MCP, tracing, or another domain-neutral primitive. **Implement downstream in AgentProlog** when the behavior is coding-product-specific: concrete repository tools, Git/process/test integrations, TUI/frontend code, editor integrations, UX, product defaults, and coding workflow composition. **Use the existing external tool-pack ABI** only for actual concrete tools/tool categories. `rlm_tool_loader` is not a general plugin loader for the runtime. **Do not treat XDG `config.prolog` as the package/plugin system.** It is trusted runtime configuration/customization, a separate concern. Never create parallel `authority_v2`, scheduler, effect ledger, verifier stack, protocol, or runtime merely to avoid an upstream change. Dependency direction remains: ```text agentProlog -> prolog-rlm ``` Never `prolog-rlm -> agentProlog`. ## Current repository state to reconcile The standalone AgentProlog repository is currently sparse while substantial implementation still exists under: ```text lost-rob0t/prolog-rlm/agentProlog/ ``` Audit that implementation and all supporting upstream docs/modules/tests, especially: - `agentProlog/` - `docs/prolog-agent-roadmap.md` - `docs/prolog-agent-ui-v1.md` - `prolog_agent_ui_v1` implementation and facade - deterministic NDJSON fixtures - TUI/reference-client work - project tool/workflow work - authority/verification integration - protocol/reconnect/replay tests Classify every relevant component as: ```text MIGRATE REUSE VIA PROLOG-RLM API REIMPLEMENT DOWNSTREAM KEEP CORE LEGACY / DO NOT MIGRATE BLOCKED ``` Reference exact files/modules/functions. Migrate useful work; do not throw it away merely because it currently lives in the wrong repository. ## Nix-only dependency authority AgentProlog must be flake-native. Create and maintain: ```text flake.nix flake.lock ``` Expose appropriate outputs such as: ```text packages.${system}.agentProlog packages.${system}.default apps.${system}.agentProlog apps.${system}.default devShells.${system}.default checks.${system}.* ``` Use repository conventions where names differ. All repository-level/external dependencies must enter through Nix flake inputs or deterministic Nix packaging. Do not require: - git submodules; - ad-hoc `git clone`; - curl-piped installers; - runtime dependency downloads; - undocumented `npm install`, `pip install`, `cargo install`, or `go install` bootstrap rituals. At minimum consume: ```nix prolog-rlm.url = "github:lost-rob0t/prolog-rlm"; ``` and make it follow the same `nixpkgs` where appropriate. If `prolog-rlm` lacks suitable flake outputs, work the corresponding upstream issue rather than copying its source into AgentProlog. Target UX: ```bash nix run github:lost-rob0t/agentProlog nix develop nix flake check ``` ## Product-side plugin architecture AgentProlog should have a small versioned plugin boundary for **product-side extensions**, not core runtime semantics. Useful plugin classes include: - frontend/TUI renderer clients; - editor clients/integrations; - coding/project tool packs; - optional AgentProlog product integrations. Loading/installing a plugin grants no capability or authority by itself. ### Tool plugins Concrete coding tools should register through the upstream external tool-library ABI (`rlm_tool_loader`) when that contract fits. Candidate initial categories/tools: ```text filesystem: project_read, project_search, project_write, project_patch git: git_status, git_diff, git_show, bounded git_apply process/test: run_tests, bounded configured process_run ``` No ambient arbitrary shell as the easy implementation. Preserve schema validation, project-root confinement, capabilities, authority, durable effects, cancellation, budgets/timeouts, traces, and stale-preimage protection. If the existing tool-pack ABI cannot safely express required concrete coding tools, fix the generic contract upstream rather than bypassing it. ### Frontend plugins Frontends consume the canonical `prolog_agent_ui_v1` snapshot/event/command contract. They must not execute tools directly, implement authority policy, become a second scheduler, or reconstruct authoritative state from pretty logs. ## Default TUI plugin Research viable general-purpose TUI frameworks using current GitHub data and rank by stars plus maintenance, license, ecosystem maturity, async/event suitability, and Nix packaging implications. At minimum evaluate: - `charmbracelet/bubbletea` - `vadimdemedes/ink` - `Textualize/textual` - `ratatui/ratatui` - `anomalyco/opentui` Research snapshot when this epic was requested: ```text Bubble Tea ~44.5k stars Ink ~39.7k Textual ~37.0k Ratatui ~22.3k OpenTUI ~13.1k ``` Refresh before implementation. Unless current evidence exposes a material blocker, use **Bubble Tea** as the default installed frontend plugin. Evaluate and prefer official `charmbracelet/bubbles` and `charmbracelet/lipgloss` for common components/styling rather than reimplementing them. Keep headless mode first-class. The TUI is only a renderer/client over the same coding workflow. ## Headless coding workflow Target one authoritative product execution path: ```text operator requirement -> normalize/validate/freeze Spec -> inspect project + instructions + current source state -> produce/accept Plan bound to the Frozen Spec -> execute bounded tools -> refresh/re-index project observations -> collect runtime/project evidence -> Verify Frozen Spec -> repair/replan on failure without weakening the Spec -> structured completion with changed files, verification, usage, trace ``` Reuse upstream `prolog-rlm` components. Do not build a coding-specific generic runtime. The same workflow must serve: ```text headless CLI Bubble Tea frontend future Emacs/Lem/other frontends ``` ## Compare old and new harnesses Produce and maintain an explicit migration matrix: | Concern | Existing nested harness | Standalone target | Migration action | |---|---|---|---| | runtime ownership | | | | | provider/model execution | | | | | async/Futures | | | | | authority | | | | | effects | | | | | Spec/Plan/Verify | | | | | project/source KB | | | | | tools | | | | | frontend protocol | | | | | UI/TUI | | | | | configuration | | | | | persistence | | | | | MCP | | | | | traces | | | | | tests | | | | | packaging | | | | Whenever the nested harness contains product code that should live downstream, migrate/adapt it. Whenever it merely consumes or demonstrates a reusable upstream contract, depend on that contract instead of copying it. ## Reuse existing work Preserve or adapt, where applicable: - `prolog_agent_ui_v1`; - NDJSON transport; - deterministic fixture server; - golden protocol fixtures; - snapshot/event/command semantics; - event sequencing and reconnect/replay; - request correlation; - unknown-tool rendering; - approval/question/cancel flows; - verification, usage, trace, subagent, and effect-indeterminate presentation; - existing TUI interaction research/code; - project tool/workflow tests. Do not fork the protocol casually merely because the renderer language changes. ## Verification Use TDD and executable evidence. Cover at minimum: - protocol ordering/reconnect/duplicate suppression; - cancellation; - approval correlation; - unknown tools and malformed frames; - stale patch failure; - path traversal and symlink escape rejection; - effect replay/no duplicate mutation; - failed tests entering repair instead of success; - Frozen Spec immutability; - frontend crash not corrupting authoritative run state; - plugin ABI/version mismatch handling; - headless mode; - Bubble Tea mode; - clean `nix build` / `nix run` / `nix flake check`; - old/new conformance where semantically applicable. GitHub Actions is the canonical full gate. Never weaken CI simply to make a slice green. ## OLD HARNESS REMOVAL GATE **DO NOT REMOVE THE OLD HARNESS.** The current implementation under: ```text prolog-rlm/agentProlog/ ``` must remain until the user explicitly gives the removal command. You may inspect, test, migrate, adapt, deprecate, and establish compatibility coverage. Do not delete it, gut it, or replace it with an empty compatibility stub. Create/retain a final cutover-removal issue and leave it explicitly blocked: ```text BLOCKED: requires explicit user authorization to remove the legacy harness. ``` Even when standalone parity is reached, stop before deletion. ## Autonomous-loop contract For every autonomous work cycle on this epic: 1. search all relevant current repository state, issue/comments, recent PRs/commits, docs/design, source, tests, and applicable upstream/downstream issues; 2. reconcile stale text against merged executable truth; 3. choose the smallest coherent next slice; 4. implement as much useful work as possible in that slice rather than stopping after one mechanical action; 5. run focused tests and required gates; 6. update docs/roadmap/issues to match reality; 7. if more non-conflicting work in the same epic is actionable, continue rather than stopping solely because one checkbox closed; 8. when blocked by a missing generic runtime feature, cross over to the linked `prolog-rlm` epic/issue instead of inventing a downstream workaround. ## Deliverables - standalone flake-native AgentProlog; - pinned flake dependency on `prolog-rlm`; - migration inventory and old/new matrix; - product plugin contract; - default Bubble Tea TUI plugin; - reusable coding tool packs using upstream loader semantics; - headless coding workflow; - migrated/reused protocol and fixture work; - conformance tests; - docs; - cutover-readiness report; - legacy harness retained pending explicit user command. Cross-link the companion `prolog-rlm` integration epic once created.
lost-rob0t commented 2026-08-21 03:53:59 +00:00 (Migrated from github.com)

Companion upstream runtime epic: lost-rob0t/prolog-rlm#141. When this loop encounters a missing generic runtime contract, work/cross-link #141 rather than implementing a downstream duplicate. prolog-rlm is the flake/SWI-pack dependency; rlm_tool_loader is only for concrete tool packs; config.prolog is configuration/customization, not package embedding.

Companion upstream runtime epic: lost-rob0t/prolog-rlm#141. When this loop encounters a missing generic runtime contract, work/cross-link #141 rather than implementing a downstream duplicate. `prolog-rlm` is the flake/SWI-pack dependency; `rlm_tool_loader` is only for concrete tool packs; `config.prolog` is configuration/customization, not package embedding.
lost-rob0t commented 2026-08-21 04:51:01 +00:00 (Migrated from github.com)

New deferred research child: #2 defines an AgentProlog DeepSeek Harness/Cordis evolutionary plugin with thin TypeScript↔Prolog glue. Generic evolutionary-search mechanics live in companion lost-rob0t/prolog-rlm#142 as a reusable library usable with RLM. This is IDEA/WAIT research, not active migration scope yet.

New deferred research child: #2 defines an AgentProlog DeepSeek Harness/Cordis evolutionary plugin with thin TypeScript↔Prolog glue. Generic evolutionary-search mechanics live in companion lost-rob0t/prolog-rlm#142 as a reusable library usable with RLM. This is IDEA/WAIT research, not active migration scope yet.
lost-rob0t commented 2026-08-21 06:31:39 +00:00 (Migrated from github.com)

Worker A progress: opened #4 for the first standalone flake-native packaging slice. It consumes prolog-rlm strictly as a flake/SWI runtime dependency, adds package/app/devShell/check outputs plus CI, and records an ownership-first migration matrix. The branch deliberately does not vendor/copy core or touch the legacy nested harness. Current blocker is upstream and concrete: prolog-rlm/main has pack.pl but no flake.nix/packages.${system}.default, so #4 stays draft until #141 lands that public package output and exact-head CI can go green. Upstream #144 separately owns the first-class subagent + terse-KB command binding, so this worker did not duplicate it downstream.

Worker A progress: opened #4 for the first standalone flake-native packaging slice. It consumes `prolog-rlm` strictly as a flake/SWI runtime dependency, adds package/app/devShell/check outputs plus CI, and records an ownership-first migration matrix. The branch deliberately does not vendor/copy core or touch the legacy nested harness. Current blocker is upstream and concrete: `prolog-rlm/main` has `pack.pl` but no `flake.nix`/`packages.${system}.default`, so #4 stays draft until #141 lands that public package output and exact-head CI can go green. Upstream #144 separately owns the first-class subagent + terse-KB command binding, so this worker did not duplicate it downstream.
lost-rob0t commented 2026-08-21 06:35:22 +00:00 (Migrated from github.com)

Upstream packaging is now active in prolog-rlm PR #145. It exposes the expected packages.${system}.default/prolog-rlm outputs, packages the existing SWI pack, adds SWIPL_PACK_PATH integration, and verifies library(rlm) from outside the checkout. Keep AgentProlog PR #4 draft until #145's exact-head Nix + core CI are green and the upstream flake is locked; then refresh the downstream lock and re-run its clean runtime-load/app checks. #144 remains separately owned by the subagent/prompt worker.

Upstream packaging is now active in `prolog-rlm` PR #145. It exposes the expected `packages.${system}.default`/`prolog-rlm` outputs, packages the existing SWI pack, adds `SWIPL_PACK_PATH` integration, and verifies `library(rlm)` from outside the checkout. Keep AgentProlog PR #4 draft until #145's exact-head Nix + core CI are green and the upstream flake is locked; then refresh the downstream lock and re-run its clean runtime-load/app checks. #144 remains separately owned by the subagent/prompt worker.
lost-rob0t commented 2026-08-21 11:32:13 +00:00 (Migrated from github.com)

Hey GPT-5.6 here. Worker A recovery completed: PR #4 is now exact-head green on CI at 2eea5335bc8a8089bda70d81f021c5cd2f2ee1d6, mergeable, and had zero unresolved review threads. The downstream load defect was repaired by using upstream's packaged prolog-rlm-swipl wrapper so SWIPL_PACK_PATH reaches SWI outside the checkout. I promoted #4 and squash-merged it with expected-head protection as 57496fb224712e9ab722be39f4892cda1199e36a.

Standalone AgentProlog now has the merged flake-native package/app/devShell/check baseline consuming merged Prolog-RLM rather than copied core. Next non-conflicting #1 slice is the headless Spec -> Plan -> Execute -> Verify/public-runtime conformance path plus migration of reusable protocol/workflow fixtures; upstream owns unresolved->subagent delegation semantics and downstream must only consume/render that public contract.

Hey GPT-5.6 here. Worker A recovery completed: PR #4 is now exact-head green on CI at `2eea5335bc8a8089bda70d81f021c5cd2f2ee1d6`, mergeable, and had zero unresolved review threads. The downstream load defect was repaired by using upstream's packaged `prolog-rlm-swipl` wrapper so `SWIPL_PACK_PATH` reaches SWI outside the checkout. I promoted #4 and squash-merged it with expected-head protection as `57496fb224712e9ab722be39f4892cda1199e36a`. Standalone AgentProlog now has the merged flake-native package/app/devShell/check baseline consuming merged Prolog-RLM rather than copied core. Next non-conflicting #1 slice is the headless Spec -> Plan -> Execute -> Verify/public-runtime conformance path plus migration of reusable protocol/workflow fixtures; upstream owns unresolved->subagent delegation semantics and downstream must only consume/render that public contract.
lost-rob0t commented 2026-08-21 12:33:21 +00:00 (Migrated from github.com)

Hey GPT-5.6 here. Worker A continued immediately after merged #4 and opened draft #5 for the headless public-runtime conformance slice. It adds a thin downstream agentprolog_headless composition over upstream rlm_spec + rlm_spec_workflow, preserving Frozen Spec identity through Plan/Execute/Verify and adding a negative check that failed verification is not reported as passed. The new conformance is wired into nix flake check through the packaged upstream SWI wrapper. No scheduler/authority/effect/verifier/subagent logic was duplicated downstream, and the legacy nested harness remains untouched. Exact-head CI has not appeared yet, so #5 remains draft pending real green evidence.

Hey GPT-5.6 here. Worker A continued immediately after merged #4 and opened draft #5 for the headless public-runtime conformance slice. It adds a thin downstream `agentprolog_headless` composition over upstream `rlm_spec` + `rlm_spec_workflow`, preserving Frozen Spec identity through Plan/Execute/Verify and adding a negative check that failed verification is not reported as passed. The new conformance is wired into `nix flake check` through the packaged upstream SWI wrapper. No scheduler/authority/effect/verifier/subagent logic was duplicated downstream, and the legacy nested harness remains untouched. Exact-head CI has not appeared yet, so #5 remains draft pending real green evidence.
Owner

Work continues in parallel under #undefined for the graphical Workbench. It consumes the same canonical frontend protocol and headless coding workflow from this epic; it must not fork runtime/authority/state semantics.

Work continues in parallel under #undefined for the graphical Workbench. It consumes the same canonical frontend protocol and headless coding workflow from this epic; it must not fork runtime/authority/state semantics.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/agentProlog#1
No description provided.