Unmix: remove a recorded development decision, then adapt retained changes through Codex MCP

[light338]

I've released Unmix, an experimental open-source local MCP server and Git
task ledger for Codex. I'd like feedback from people who have changed their
mind about an earlier feature after building related features on top of it.

Problem: remove mandatory registration while keeping checkout, receipt
export and a rounding fix. A file-level revert doesn't express what should
survive or how dependent features should work afterward.

Workflow: record each task with intent, dependencies and checks using
unmix_begin / unmix_finish. unmix_prepare creates a separate candidate
worktree and replays retained patches. Codex inspects snapshot diffs, adapts
conflicts or removed dependencies, stages repairs and calls unmix_resume.
unmix_verify and unmix_inspect expose check results and stale verification.
The original files, branch and index remain intact.

Evidence: a real authenticated Codex CLI recorded four notebook tasks over
stdio MCP, removed mandatory author identity and adapted tags, normalization
and JSON export. Five check commands passed. An independent audit confirmed
the original files/HEAD/index/status, retained tests and external oracle were
unchanged. The repository also has 14 offline tests and successful CI on Node.js
22 and 24. Development used substantial AI assistance.

Limits: this is one synthetic workflow, not proof of general semantic
correctness. Tasks need recording before editing; dependencies are declared;
core verification does not yet freeze arbitrary test files. The included shop
demo has prewritten repairs, while the separate live notebook test uses actual
model-written adaptations. No external adoption is claimed yet.

• Source: https://github.com/light338/unmix
• Experimental release: https://github.com/light338/unmix/releases/tag/v0.1.2
• First-project walkthrough: https://github.com/light338/unmix/blob/main/docs/first-project.md
• Live test details: https://github.com/light338/unmix/blob/main/docs/live-codex.md

There are no npm dependencies, telemetry or hosted backend. Node.js 22+, Git and
existing Codex access are enough. To connect:

codex mcp add unmix -- node /absolute/unmix/bin/unmix.mjs mcp --repo /absolute/project

I'm looking for one real change-of-direction attempt per tester on a small
project: what was removed, what survived, what broke and whether you would use
this again. Please share a report through the repository's First-use report
form, without private source or secrets. Cases where tests pass but a retained
behavior is lost are particularly valuable. Feedback on the MCP workflow and
task recording burden would also help.

[bomtobe-hgkim]

I'm with BOMTOBE, the team behind orke; I haven't tested Unmix. The candidate worktree plus declared dependencies sounds like a useful boundary. One thing I'd want to inspect in a change-of-direction run is the resulting diff grouped by retained task, with conflicts or skipped patches called out before checks run. Does unmix_prepare expose that mapping clearly enough to review what survived and what was adapted?

[light338]

Thanks for the concrete review criterion. In v0.1.2, the task metadata is exposed, but the final diff is not yet presented as a complete task-grouped review report.

unmix_prepare returns the plan with:

• Retained tasks, including taskId, intent, declared dependencies, affected files and original before/after snapshots. Each task has a replay state: pending, replayed, needs_adaptation or, after resuming, adapted.
• Explicitly removed tasks in removedTasks.
• The first blocker in blocked: its task ID, patch_conflict or removed_dependency, removed dependency IDs and Git's diagnostic output.

Replay stops at that blocker, so later tasks remain pending; they are not silently skipped. A declared dependency on a removed task also triggers review even if the patch applies cleanly. After the agent repairs the candidate, unmix_resume records an adaptation note for that task and continues replay. unmix_verify refuses to run while a blocker or pending retained task remains. This exposes blockers incrementally, rather than discovering every possible conflict upfront.

The gap you identified is real: unmix_inspect currently returns the plan metadata plus an aggregate diff against the base. Original per-task patches are inspectable through their snapshot pairs, but a structured original-versus-adapted diff for each retained task is not returned directly. Replay status also doesn't prove that the task's behavior survived; that still needs review and behavioral checks.

A per-task review report showing original patch, resulting patch, adaptation note and replay outcome would make that boundary much easier to audit. The current implementation is here: prepare/replay/resume/inspect.

[light338]

@bomtobe-hgkim I added this specifically in response to your feedback and released Unmix v0.1.3. Thanks for identifying the missing review step.

The new unmix_report MCP tool (and report CLI command) returns JSON or Markdown with:

• Each retained task's original patch and recorded resulting patch, replay outcome and adaptation note.
• Conflict/removed-dependency history, retained after repair.
• Intentionally removed tasks, pending tasks and the current blocker, listed separately.
• Additional candidate edits outside completed task snapshots, plus the aggregate diff and check freshness.

It works before checks and does not execute them. unmix_prepare now points to the report tool; the repair prompt asks the agent to review it before verification.

Here's an actual generated report and the usage/evidence details. The example uses an explicitly authored repair, not a new live model run. All 18 tests pass, including CLI/MCP report calls, with CI passing on Node.js 22 and 24.

Two limits remain explicit: these are historical task deltas, so later tasks may overwrite earlier changes; and plans prepared before v0.1.3 lack result snapshot pairs, so a new plan is needed for the full report. It still doesn't prove semantic preservation.

If you try it, I'd be interested in whether this makes the survived-versus-adapted distinction clear enough to review.

[bomtobe-hgkim]

Thanks for adding the report step. Separating a readable report from running checks makes the review point explicit. I have not tested v0.1.3, but the boundary you described is useful. Appreciate the quick follow-up.

[light338]

@bomtobe-hgkim Thanks again for the thoughtful feedback — it helped make the review step clearer. If you get a chance to try Unmix and find it useful, I'd be glad to hear how it worked for you. Any rough edges or confusing parts would be just as helpful to hear about.

[TheodorNEngoy]

I haven’t run Unmix yet. In Turnfeed, “Like saved” and “the page keeps its scroll position” needed separate checks. If I manually verify the interaction, then Codex adapts another retained task, does Unmix tie that manual result to the candidate snapshot and mark it stale, or should I track it separately?

I’m comparing practical Codex workflows with other users on Turnfeed. I’d welcome your approach to that kind of human check in the discussion: https://turnfeed.theodornengoy.chatgpt.site/post/post-25

Written with Codex assistance.

[TheodorNEngoy]

Thanks for adding this so quickly. I read the v0.1.4 workflow: separate interaction IDs and stale results after a candidate change address the tracking gap I described. The explicit limits around browser/database state and caller-supplied observations are helpful too. I haven’t run this release, so this is a documentation acknowledgment rather than a test result. Appreciate you following up.

Written with Codex assistance.

[light338]

@TheodorNEngoy Your point about keeping “Like saved” and “scroll position preserved” separate led me to extend this in v0.1.7 with an opt-in preservation passport.

You can now declare both interactions as required, separate IDs before adaptation. Each obligation is bound to a command or a manual check ID plus its procedure. Unmix compares evidence against a separate recorded-original worktree and the candidate. Passing automated commands cannot make the passport ready while a required manual observation is missing, failed or stale. Reports show each obligation’s original/candidate evidence and unmet IDs for the agent to address; there is no tool to drop or rewrite an obligation during that plan.

Preservation criteria need passing evidence on both versions. A desired removal behavior can instead require a failing original and passing candidate. Pre-existing failures and removal criteria that already passed on the original remain explicit.

Workflow and limits · Generated example

All 45 integration tests pass, including CLI/stdio MCP. The example uses authored repairs and synthetic observations, not a new live-agent or human/browser test. Manual observations remain caller supplied; freshness still excludes browser/database/runtime state. If you try it, I’d be glad to hear whether the required-interaction checklist fits your workflow.

Written with Codex assistance.

[TheodorNEngoy]

Thanks for making “Like saved” and “scroll position preserved” separate required checks before adaptation. I’ve read the v0.1.7 guide but haven’t run it. For a real run, I’d also record the browser/account state alongside each observation, since that remains outside Git-tree freshness.

Written with Codex assistance.

[light338]

@TheodorNEngoy I added the browser/account context you suggested in v0.1.9. Each original/candidate phase can now declare browser/version, environment, test-account/auth state, session and data labels. Each manual observation stores that context and its revision alongside the Git tree.

Changing a declaration marks earlier observations stale even when code is unchanged; reports compare the original and candidate conditions, and contextual passports block missing/unknown conditions or mismatches. Rechecking one interaction still does not refresh another.

These are caller-declared conditions, not automatic browser monitoring: undeclared browser/database changes remain undetected. The 70-test suite and Node.js 22/24 CI pass; the new context tests use synthetic observations, so this is not a claim of a new real-browser trial. Workflow and limits.

Thanks for the concrete suggestion. If you try a small run, I would especially value feedback on whether these labels capture enough context for your separate Like/scroll checks. Written with Codex assistance.

[TheodorNEngoy]

Thanks for adding this. I read the v0.1.9 guide: recording the context revision with each observation, and keeping earlier results stale after a declaration changes, makes the separate Like/scroll checklist clearer. I haven’t run this release, so I can’t yet judge whether the labels cover a real session. Appreciate the follow-up.