[P0][feature-freeze] Run API/expert hardening queue with Auto-Dig dogfood repair loop #300

New issue

Open

opened 2026-09-02 17:25:36 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-02 17:25:36 +00:00

Owner

Worker

prolog-rlm-rage-hardening

Goal

Operate the Prolog-RLM feature-freeze hardening lane as a bounded issue-driven loop. Work only on the current expert-system/API-hardening set, correctness regressions, load/packaging/CI failures, and Auto-Dig integration defects that expose generic Prolog-RLM problems.

This is an operational queue task, not permission to start broad new feature epics.

Current priority inputs

Re-read current main and live issue state before every slice. Initial known candidates include current runtime/API regressions such as:

#328 circular rlm_completion / rlm_direct import collision;
#329 singleton-variable load warnings;
#323 native-call batch cardinality admission budget;
#327 current CI failure if still applicable;
Auto-Dig integration failures/issues such as #285/#277 and generic integration gaps such as #296/#297, only where still reproducible/current.

Merged code/tests outrank stale issue prose. Do not blindly implement this list if current main has already resolved something.

Loop contract

For each cycle:

inspect current main, open PRs, current eligible issues, CI and applicable AGENTS.md/docs;
select exactly one bounded unblocked hardening slice;
establish RED/reproducer or another falsifiable acceptance proof;
implement the smallest generic runtime/API correction;
run focused tests plus the repository deterministic gate;
when the slice affects Auto-Dig, launch the real Auto-Dig runner/integration path and inspect the result;
if Auto-Dig exposes another generic Prolog-RLM defect, open/fix the focused upstream defect rather than patching around it downstream;
open/update one focused PR with exact-head evidence;
continue to the next eligible hardening issue only after the current slice is verified/handed off.

Auto-Dig dogfood rule

Auto-Dig is a downstream integration oracle, not a source of product policy for Prolog-RLM.

Use it to exercise:

provider/direct-mode integration;
MCP/read-only research tool projection;
prompt/compiler/runtime limits;
structured failures, cancellation and usage;
load/packaging/runtime compatibility.

If the runner itself is broken, fix the runner/integration wiring as needed to restore a truthful Prolog-RLM dogfood test, while keeping generic runtime behavior upstream and Auto-Dig-specific behavior downstream.

Feature-freeze exclusions

Do not autonomously start broad work on:

new retrieval stacks;
skill refinery/evolution programs;
unrelated standard tool catalogs;
new persistence subsystems;
speculative architecture unrelated to the current expert/API hardening set.

An open issue alone does not make it eligible during the freeze.

Acceptance

current eligible hardening queue is continuously reduced through issue-scoped PRs;
every behavioral fix has a meaningful regression/conformance proof;
real Auto-Dig integration is run when relevant rather than inferred from unit tests;
Auto-Dig-discovered generic defects become focused Prolog-RLM fixes;
complete deterministic gate is green at each completed exact head;
no broad frozen feature work is smuggled into a hardening PR;
reports identify selected issue, exact branch/head, RED/GREEN evidence, Auto-Dig result when applicable, and next eligible issue.

## Worker `prolog-rlm-rage-hardening` ## Goal Operate the Prolog-RLM feature-freeze hardening lane as a bounded issue-driven loop. Work only on the current expert-system/API-hardening set, correctness regressions, load/packaging/CI failures, and Auto-Dig integration defects that expose generic Prolog-RLM problems. This is an operational queue task, not permission to start broad new feature epics. ## Current priority inputs Re-read current `main` and live issue state before every slice. Initial known candidates include current runtime/API regressions such as: - #328 circular `rlm_completion` / `rlm_direct` import collision; - #329 singleton-variable load warnings; - #323 native-call batch cardinality admission budget; - #327 current CI failure if still applicable; - Auto-Dig integration failures/issues such as #285/#277 and generic integration gaps such as #296/#297, only where still reproducible/current. Merged code/tests outrank stale issue prose. Do not blindly implement this list if current main has already resolved something. ## Loop contract For each cycle: 1. inspect current `main`, open PRs, current eligible issues, CI and applicable `AGENTS.md`/docs; 2. select exactly one bounded unblocked hardening slice; 3. establish RED/reproducer or another falsifiable acceptance proof; 4. implement the smallest generic runtime/API correction; 5. run focused tests plus the repository deterministic gate; 6. when the slice affects Auto-Dig, launch the real Auto-Dig runner/integration path and inspect the result; 7. if Auto-Dig exposes another generic Prolog-RLM defect, open/fix the focused upstream defect rather than patching around it downstream; 8. open/update one focused PR with exact-head evidence; 9. continue to the next eligible hardening issue only after the current slice is verified/handed off. ## Auto-Dig dogfood rule Auto-Dig is a downstream integration oracle, not a source of product policy for Prolog-RLM. Use it to exercise: - provider/direct-mode integration; - MCP/read-only research tool projection; - prompt/compiler/runtime limits; - structured failures, cancellation and usage; - load/packaging/runtime compatibility. If the runner itself is broken, fix the runner/integration wiring as needed to restore a truthful Prolog-RLM dogfood test, while keeping generic runtime behavior upstream and Auto-Dig-specific behavior downstream. ## Feature-freeze exclusions Do not autonomously start broad work on: - new retrieval stacks; - skill refinery/evolution programs; - unrelated standard tool catalogs; - new persistence subsystems; - speculative architecture unrelated to the current expert/API hardening set. An open issue alone does not make it eligible during the freeze. ## Acceptance - current eligible hardening queue is continuously reduced through issue-scoped PRs; - every behavioral fix has a meaningful regression/conformance proof; - real Auto-Dig integration is run when relevant rather than inferred from unit tests; - Auto-Dig-discovered generic defects become focused Prolog-RLM fixes; - complete deterministic gate is green at each completed exact head; - no broad frozen feature work is smuggled into a hardening PR; - reports identify selected issue, exact branch/head, RED/GREEN evidence, Auto-Dig result when applicable, and next eligible issue.

nsaspy referenced this issue

2026-09-02 17:26:30 +00:00

[CI failure] CI on fix/298-native-any-json-schema #321

nsaspy referenced this issue

2026-09-02 17:26:31 +00:00

[CI failure] Paid OpenRouter on fix/298-native-any-json-schema #320

nsaspy commented

2026-09-08 01:43:59 +00:00

Author

Owner

2026-09-05 queue audit: stale inputs #327, #277 and #285 are now closed after their parent/superseding work landed; do not select them. The newly created expert-system program #376–#387 is an explicit operator-directed program and is not an accidental broad-feature expansion from this autonomous hardening queue. Keep #334 focused on current reproducible hardening/CI/integration defects while expert implementation proceeds under its own epics.