Add Dulus Ai Harness

[KevRojo]

No description provided.

[lefarcen]

Adding a new runtime adapter is a useful direction. Could you fill in the PR description with Why / What users will see / Surface area / Validation so reviewers have the right context? Since this changes runtime behavior, we'll also queue a manual QA pass before merge.

[PerishCode]

This adapter’s argv and registration wiring match the current published CLI, but the stdout contract is not safe for OpenDesign’s plain-stream success path. The inline blocker needs to be resolved before this runtime is exposed.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[PerishCode]

Do not route Dulus’s current terminal stdout directly through the plain assistant stream. The published 3.11.22 --print path unconditionally prints a license/startup status before entering repl(), and run_query() uses the terminal renderer for status, tool, warning, and error output; it does not provide a stdout channel containing only the final assistant reply. OpenDesign’s plain handler forwards every stdout byte as assistant text and treats non-empty stdout as substantive output, so a startup banner or provider error can pollute the reply and can make a failed run appear successful. Add/use a Dulus machine-output mode that separates protocol output from diagnostics, or add a dedicated normalizer with explicit terminal/failure detection, then cover the real process boundary with fixtures for a successful response and an auth/provider failure. The existing buildArgs unit tests cannot prove this wire contract.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[PerishCode]

@KevRojo I verified the live PR at the seeded head and found that it currently has no changed files or changed ranges against main; the earlier Dulus adapter changes and their previously flagged stdout behavior are no longer present in the review diff. Thanks for following through on the revision and leaving the branch in a clean, no-op state for this pass.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[KevRojo]

I'm solving it El vie, 28 ago 2026 a la(s) 1:58 p.m., PerishFire ***@***.***) escribió:

…

***@***.**** approved this pull request. @KevRojo <https://github.com/KevRojo> I verified the live PR at the seeded head and found that it currently has no changed files or changed ranges against main; the earlier Dulus adapter changes and their previously flagged stdout behavior are no longer present in the review diff. Thanks for following through on the revision and leaving the branch in a clean, no-op state for this pass. 🔁 Powered by Looper <https://github.com/nexu-io/looper> · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos. — Reply to this email directly, view it on GitHub <#7572?email_source=notifications&email_token=ACFFJJDBUSWMQIKZWN7XNSD5MHB4RA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMBVGM3TANRQGEY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#pullrequestreview-5053706011>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFFJJGNFYSPWHNYW4B35CL5MHB4RAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMRTGE3TAMRZGA5US43TOVSTWNJSHAYDEOJYGI2TTILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Kevin Rojo Ceo/Founder

[lefarcen]

Got it. Once you push the next implementation, we can review that head — right now this branch is still a no-op against main.

[PerishCode]

The new JSON protocol path resolves the earlier stdout-contamination problem, but the minimum-version requirement is currently documentation-only. An older installed Dulus remains selectable and can reproduce the false-success behavior this revision is intended to prevent.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[PerishCode]

Enforce the stated Dulus 3.12.1 minimum before exposing this runtime as available. These changed lines only run --version; with no compatibility gate, detectAgent accepts any non-empty version, and even the existing versionPolicy mechanism leaves unsupported-but-parseable versions available with a warning. That means 3.12.0 is still selectable even though lines 9–12 document that its provider-error path emits a text frame and exits 0, causing a failed run to appear successful. Add a fail-closed compatibility/minimum-version check (for example, a Dulus-specific compatibility probe or an explicit strict minimum-version contract), and add detector tests proving 3.12.0 is unavailable while 3.12.1 and later remain available.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[lefarcen]

Thanks for pushing the new revision. The current blocker is @PerishCode's latest review: detection needs a fail-closed gate for Dulus versions below 3.12.1 so 3.12.0 cannot still show up as available. Once that compatibility check and the detector coverage are in, the next pass can review the updated head.

💡 To drive this PR to merge hands-free, paste this to your AI coding agent (Claude Code / Codex / opencode / Cursor …):
Take over nexu-io/open-design#7572 until it merges — read https://raw.githubusercontent.com/nexu-io/looper/main/skills/pr-takeover/SKILL.md and follow it.

[KevRojo]

Addressed the minimum-version blocker at the new head (2b5f269).

The 3.12.1 floor is now enforced, not just documented, using the repo's own fail-closed machinery:

• parseDulusVersion() normalizes dulus --version (dulus v<semver>) and returns null for any build below 3.12.1 — including a prerelease of the floor (3.12.1-rc.1), which precedes the release and is still a pre-fix build.
• versionPolicy: { requireVersion: true, parse: parseDulusVersion, supportedVersions: ['3.12.1'], supportedVersionPattern: /^3\.(?:1[2-9]|[2-9]\d)\.\d+$/ } — a null version now routes through detectAgent to unavailableAgent, so an installed 3.12.0 is not selectable and cannot reproduce the false-success path. A newer parseable version off the exercised line (e.g. 3.13.0, 4.5.0) stays available with the usual untested-version warning, matching the other adapters.

Detector-boundary tests were added (they spawn a fake dulus bin that answers --version with the real dulus v<semver> line, so the gate is exercised across the actual process boundary):

• unavailable: 3.12.0, 3.11.22, 3.12.1-rc.1
• available: 3.12.1, 3.13.0; 4.5.0 available-with-warning
• plus unit coverage of the parser (accept/reject table, build-metadata, empty/garbage lines)

Ready for another pass.

[PerishCode]

@KevRojo I reviewed all changed ranges and verified the Dulus adapter against the upstream v3.12.1 CLI contract. The JSONL transport now keeps terminal diagnostics off stdout, maps the published OpenCode-compatible frames through the existing parser, and fails provider/auth errors instead of presenting them as assistant replies. I also checked that the new fail-closed version policy makes pre-fix and prerelease builds unavailable while preserving the repository's warning behavior for newer untested versions, with detector-boundary coverage for each case. Thanks for carefully following through on both earlier blockers and adding focused regression coverage around the risky process seams.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[KevRojo]

@lefarcen friendly nudge on this one — both reviewer blockers are resolved and the PR is green:

• stdout contract fixed (terminal diagnostics kept off stdout; provider/auth errors now fail instead of surfacing as assistant replies)
• fail-closed 3.12.1 minimum-version gate is enforced (not just documented), with detector-boundary + parser regression tests

@PerishCode approved at the latest head (2b5f269) and all checks pass. Review decision is APPROVED but the PR is still in a BLOCKED merge state (labeled risk/high), so it looks like it's waiting on the manual QA pass you mentioned.

Whenever you get a chance to queue that QA and merge, I'd appreciate it. Happy to answer questions or add anything else that helps. Thanks!

[lefarcen]

Thanks for the nudge. As of August 29, 2026, this PR is not queued for a manual QA pass on my side — skip-validation is already set on it, so I’m not opening a separate QA handoff here.

The current head already has @PerishCode's approval, so there isn’t anything else needed from you right now unless a maintainer asks for a follow-up change.