Releases: ceceppa/mano
Release list
v1.6.2
Workflow rules now agree on who approves phase scope, how an approved auto chain survives a session reset, and which commands can run during an existing phase. The three local settings stopped being Git config, and a correction you type mid-build stopped asking you to approve your own sentence.
Changed
-
Auto chains repair clear artifact gaps before build. Before either ledger exists, an unambiguous repair can insert
spec,ux,ui, orrules, then rerun full build readiness. The chain persists one attempt per owner; explicit skips, product decisions, scope changes, and unsuccessful repairs still pause. Start now explicitly includes spec for state removal or replacement. -
Auto chains retain the approved run plan.
chain.js savestores the remaining actions in their approved order in the owner's settings file, including human-added actions.chain.js show --phaseand the state projection expose that plan. Planning and implementation handoffs save progress; an empty plan records completion. If a previous session left no plan, Mano recovers approval from chat or asks the human instead of inferring it from artifact existence. Explicit skips remain separately recorded. -
mano owner,mano mode, andmano trackno longer live in Git config. Preferences and chain records are plain JSON in_mano_output/[owner].json(.default.jsonwith no owner configured), which you can commit alongside the phase artifacts and pick up on another machine —mano owner alice, thenmano continue. Only the per-checkout owner selection stays local, in_mano_output/.local.json, which Mano adds to_mano_output/.gitignoreitself. The newsrc/scripts/settings.jsowns reading, validating, and atomically writing those files;chain.js,mode.js,owner.js,phase.js, andtrack.jsall shed their owngit configcalls and go through it. Two consequences worth naming: settings no longer require a Git checkout at all —mano mode autoin a fresh directory just works, and the old "rungit initfirst" instruction is gone — and an owner's mode, track, skips, and approved run plan now travel with the project instead of dying with the clone.MANO_OWNER/MANO_MODE/MANO_TRACKstill override for one shell or worktree without being saved. Existingmano.owner,mano.mode,mano.track,mano.chain.*, andmano.run.*keys migrate on first read, per owner, and only where the JSON has no value for them: a written value always wins, including a cleared setting and a finished chain, so a migration never reopens something you closed. -
A clear in-goal correction is implemented, not re-approved.
mano build "[what changed]"case (C) used to append the+Nrow, fire the deviation stop, and wait — which asked the human to approve the sentence they had just typed. It now records the row, runs the gap gates against it, then implements and verifies in the same run, in both manual and auto mode, and shows the row and its Exit link as progress rather than as a permission question. The gates are untouched and still stop first: an unresolved artifact gap still routes to the owning skill with no code, a distinct outcome is still case (B), and a correction that is ambiguous, conflicts with an existing contract, or needs a new Exit Criterion still asks — but it asks the specific question, once, and continues on the answer instead of demanding a second "approve to implement". Splits and out-of-report reopens remain deviation stops.
Fixed
-
Import can retire superseded backlog work. Document merges can reject existing
Status: backlogitems when the human authorizes replacing their direction, preserving the reason and source. Scoped and closed items stay unchanged; merge permission alone does not authorize rejection. -
Human-approved scope overrides are consistent. Start still proposes one independently verifiable outcome, but its forbidden list no longer contradicts the rule allowing a human to approve multiple outcomes without a routine warning about mixed scope. Advisories require a concrete consequence for the selected work; necessary product questions still apply.
-
Planning reruns respect the existing ledger. Next-action guidance uses validated state instead of assuming planning always happens before implementation. A rerun no longer selects a different implementation path merely because of the current mode.
-
UI gaps can be repaired without a phase brief. The dispatcher now recognises UI's gap-only mode, avoiding a redirect to Start when unresolved gaps prevent Start from scoping a phase.
-
Follow-up review's backlog exception is explicit. Shared backlog rules now match the existing permission to mark exact, human-confirmed open items resolved during a follow-up review. The exception does not close phases or change unrelated statuses.
-
UI/UX change requests remain implementation work. Build deferral, review triage, and intake distinguish scopeable product changes from artifact gaps. Rework harvesting no longer treats deferred requests as implemented corrections. Genuine gaps still block Start; updating a design brief or UX flow does not complete an implementation request.
-
Regression coverage. Chain tests cover preserved ordering, phase isolation, partial progress, invalid-plan rejection, and the distinction between completed runs and missing approval records. New settings tests cover resuming from a committed clone, per-owner isolation, the excluded local selection, working with no Git repository, transient environment overrides, refusing to overwrite invalid JSON, and the migration cases — including that existing JSON preferences, cleared state, and completed runs are never resurrected by a legacy Git config key.
Documentation
- The settings docs describe the files, not the Git commands. README's "The three local settings are plain Git config" section is gone, replaced by the file table (
[owner].json,.default.json,.local.json, and which to commit), an annotated owner file with a chain in progress, a field-by-field reference, and the three steps for continuing on another computer.workflow.md,_mano/rules/core.md, and the site's owners, tracks, and auto-mode pages carry the same correction. - A Get started page.
site/getting-started.mdwalks a new project fromnpx mano-plan installto a scoped first change and the choice of implementation path; the features index and landing page were reworked around it. The site also grew a sitemap, per-page canonical and Open Graph/Twitter metadata, page descriptions,robots.txt, and anoindex404. - Mano plans Mano. The repository now carries its own installed
AGENTS.mdandCLAUDE.mdentry points, so the framework is developed under the contract it ships.
v1.6.1
mano review closed a phase and reopened it in the same turn, and left behind the one state no command could read back.
Phase 3 of a piano chord explorer. Everything built, every criterion met, review opened its answer gate. Two findings came back with the answers: "Q2 - yes, but I'd show the scale ones tho. Now it repeats across all the sections and is confusing", and "Actually one exit criteria E3b — partially met: when I select 'scale' I don't want to see the chord notes." Both real, both correctly triaged. Then STEP 3 ran, and it ran all of itself: two R… rework events written into the ledger, two backlog items written for the same two findings, the close sweep flipping every in-phase-3 item to resolved, and the Phase 3 review record appended to reviews.md.
So the backlog said the phase shipped, reviews.md said it was reviewed, and progress.md said two findings were still pending. mano start refused to scope phase 4 — correctly, on its own terms — over work the human had just been told was done. There was a way out, and the projection even printed it (run mano build to work the first pending R… event), but nothing in the artifacts admitted the phase was in two states at once, and the report that came back was, reasonably, "I'm in an impossible state."
Nothing malfunctioned. STEP 3 is written as a one-shot execution, and only sign-off carried the condition — "do not run it when the review produced findings that route back to build". The close sweep and the review record carried none, so the half that reopens the phase and the half that closes it were guarded by one clause between them. The rule directly above made it worse rather than better: close it arriving with a negative finding closes the phase; it does not erase the finding told review to close and route the finding to rework — two things progress.js sign-off and state.js have always defined as mutually exclusive.
The double-write was the quieter half. R3 and R4 were also "Scale markers repeat across every keyboard section" and "Scale-only view still shows chord notes", sitting open in the backlog. Fixing the rework would have left both items Status: backlog and phase-scopeable — the same work re-proposed as new scope a phase or two later, with nothing in either file hinting they were twins.
Changed
mano reviewcloses a phase and never reopens one.request-reworkandresolve-reworkare gone from its contract;sign-offis its only remainingprogress.jssurface, and it is the one that closes. Every finding a review confirms is now a backlog item — a 🐛 Defect and a failed Exit Criterion exactly like a ✨ New idea. The routing rule is one sentence with no branches in it, which is the point: the previous version had two, and picking wrong produced a phase that wasresolvedand in progress at the same moment.- A finding you want fixed inside the phase has a better route than review ever offered. Leave the review unclosed, run
mano build "[the change]", review again after. Build classifies your exact text A/B/C and re-runs the gap gates against it — so a change with tech-spec or design-brief impact stops and routes there, which a rework event written blind at review never did. That is the specific worry the piano report raised: "the change I've asked could have impact on spec or other artifacts." Review names the option when the finding plainly belongs in this phase, and never takes it for you. mano buildis the only writer of anR…event.progress.js request-reworkaccepts--source buildand nothing else, and defaults to it.source: reviewstays readable in ledgers written before this release.
Fixed
- Both halves of the close now refuse on the same condition.
progress.js sign-offhas always refused while a rework event is pending.backlog.js resolve— the sweep that actually closes a phase — never looked at the ledger at all; it did not so much as openprogress.md. It now reads the phase's ledger and refuses with the pending event ids, writing nothing. Prose is one half of this fix and the weaker half; a state reachable by a script is a state that will be reached. - The same finding no longer lands in two ledgers. With rework off review's surface, a confirmed finding has exactly one home. There is no longer a version of it that survives its own fix and comes back as new scope.
- A criterion you report as failed is left as a disagreement, on purpose. The ledger keeps what the build proved when it ran; the review record keeps
failedwith your words; the backlog item carries it forward. Review does not reach intoprogress.mdto reconcile the two — a ledger edited at close to agree with the review erases the only evidence they ever disagreed. - Eval coverage.
review-build-findingandreview-close-with-findingnow assert the inverse of what they asserted before: noR…event opened at review, a backlog item written, no Scope or Exit row moved. Six script tests cover the two new refusals, including that they fire on the same condition and that a phase with no ledger still closes normally.
