Skip to content
Shipped and released

Now

Page 8 of 14. Every release ever published is still here — across these pages, in theAtom feed, and at its own permanent link. Nothing is dropped as it ages.

Released highlights, page 8

  1. core 2.26.17

    • A plan now names the production code each of its checks drives. A task's Tests: bullet already owed the suite it lives in, the fixture carrying a join key, and the shipped assertion the change moves; it now owes the production code the check exercises as well. A reader of a plan written from here on can see what each check is meant to hold against without opening the test.
    Release notes for core 2.26.17
  2. core 2.26.16

    • A spec now opens with what changes, not with an essay. The Objective section is renamed Outcome and capped at two sentences — who this is for, and what success looks like for them — and a new What Changes section sits right under it carrying the delta as bullets. A reader landing on a spec cold gets the shape of the change in the first screen instead of hunting for it.
    • Boundaries is now called Agent Rules. Same three tiers, same meaning, a name that says what the section does. Specs written before this keep the old heading and stay valid: every reviewer that reads the section now recognises both names.
    • The Assumptions section holds open questions only. It used to be an audit trail — every fact the author checked, with a citation for how. Those facts now go where they do work: a fact that bounds the delivery goes into the spec body, a fact that shapes how it is built goes into the plan's design. What is left in Assumptions is what nobody has answered yet, so a reader sees the gaps instead of scrolling settled ground.
    • A plan's Changelog records approvals and nothing else. The dated diary of how the approach evolved is gone; the two approval entries, which are the only record of when the contract froze and on whose authority, stay exactly as they were.
    • A plan task writes an Approach only when it has a decision to record. Where a task's Tests and Done when already say what to build and how it is observed, the Approach was restating them. It is now written for an ordering or a seam decision a reader cannot otherwise infer.
    • New advisory guidance on prose that reads as generated. A prose-discipline reference gives the author a signal-word scan, a list of canned rhetorical shapes, and the rule that the repair is restructuring rather than swapping synonyms. It is advice, never a gate, and it defers the form rules to the output-rendering block each skill already carries.
    Release notes for core 2.26.16
  3. architect 0.15.11

    • Design docs now match the size of what they describe. Writing about a whole application or system, a single subsystem, or a change to an existing architecture each gets its own template, so a reviewer no longer has to fill in eight generic sections that half apply and skip the rest.
    • Every modelled section leads with its model, not a page of prose about it. Each template opens with the question the section answers, and where the section carries a diagram or table it puts that first and only then explains why it looks that way — so a reader can see the shape of a decision before reading the argument for it.
    • A new rubric says how many documents a design needs, not just what goes in one. Six criteria decide whether a part of a subsystem deserves a document of its own, so a design doesn't grow past its own boundary just because a subsystem's story kept expanding, and a parent document says plainly what it still owns once children split off.
    • Existing links to the earlier design-doc template keep working. It stays at the same path and now says plainly what it is: a kept pointer to the three templates, never chosen for a design itself.
    • Design and review now speak the same three scopes. The review checks ask the same scope-shaped questions the templates were written to answer, so a design that follows its template's model doesn't get marked down against a checklist that expected different sections.
    Release notes for architect 0.15.11
  4. architect 0.15.9

    • Choose the right Mermaid layout for your renderer. The diagram guidance now explains that releases before Mermaid 12 default to dagre and need a separate ELK package, while Mermaid 12 and later default to bundled ELK.
    Release notes for architect 0.15.9
  5. core 2.26.15

    • A wave can no longer be signed off without saying who did the work. The step that closes a wave used to pass no matter what: it returned success for any state it could read, so a wave whose tasks were never dispatched looked exactly like one where every task was done. It now asks for one short record per task in the wave — either "this was dispatched" or a declared reason it was not — and refuses the exit by name when a record is missing, listing the tasks it could not account for rather than a count. The sibling command that steps the wave pointer forward asks for the same thing, so the check cannot be walked around by moving the pointer first.
    • Nothing already in flight breaks. A run whose state predates this feature carries no records at all, and the exit passes it with a notice saying enforcement is off rather than blocking it, so an upgrade mid-run still finishes. loop-cohort status reports whether records are being enforced.
    • A run that genuinely has no implementer can still proceed. A wave task can be declined for one of two declared reasons — no implementer is installed, or a human directed the work another way — and a declined task counts as accounted for.
    Release notes for core 2.26.15
    • The frontend pre-flight now reads the design handoff your team already wrote, instead of picking an aesthetic direction of its own. Point [design] output_dir at your design directory and it takes the aesthetic direction, the per-screen brief and the token taxonomy from there. Its own canonical reference list is now only the fallback, and only for a slot no artifact filled.
    • It keys on no section name inside your files. Design templates are scaffolds people edit, so a reader that looked for named sections would find nothing in most real documents — it takes the first heading, the frontmatter as it finds it, and the body whole.
    • A file under a read path that is not the artifact — a different type:, a draft, another kind of design record — is skipped and the scan continues. A design directory holding many kinds of document is expected, not an error.
    • When the directory is a personal vault or anywhere outside the repository, it asks you about each artifact before using it, and shows you what it found. Nothing in these files says which product they belong to, so that confirmation is the check — it is never reported as though a test had passed.
    • Every refusal stops the whole read and halts, by name. It does not tidy up a bad value, pick a different file, quietly downgrade to a skip, or fall back to the canonical list. [Read the design handoff](../../guides/frontend-engineering/how-to/read-the-design-handoff.md) says what each skip and each refusal means, and where the limits are.
    Release notes for frontend-engineering 0.3.0
  6. experience-design 2.0.6

    • Compare creative directions on shared terms. Each direction now records its commitments across fifteen named axes, including seven structural axes, so teams can identify a meaningful difference instead of arguing from taste.
    • Test whether a direction is distinctive before carrying it forward. A counterfactual pass reworks a similar brief, then records changes wherever the result falls back to a generic default.
    • Start with a named visual direction. Swiss / International Typographic, editorial broadsheet, and Bauhaus directions provide ready-made starting points for exploration.
    • Check that candidate directions truly diverge. A divergence audit identifies the closest pair, showing whether the options differ in substance rather than only on average.
    • Review a surface through two published instruments. Design reviews can now rate perceived quality and perceived genericness separately.
    Release notes for experience-design 2.0.6
  7. core 2.26.14

    • A plan now records who approved it, and when. Approving a spec and plan froze the contract and left no trace in the artifacts of when that happened or on whose authority. Reading a shipped delivery months later, you could not tell which claims were in the contract at approval and which arrived during the work — the plan's own history started at drafting and resumed at execution, with the gate itself unmarked. Each approval is now a dated entry in the plan's changelog, written by the approver in the same edit that sets the status.
    Release notes for core 2.26.14
  8. governance-extras 0.11.0

    • New ADRs now record how easy a decision is to reverse and which areas it touches. The new-adr template adds Reversibility and Areas fields, plus four supersession fields that stay none until a decision is actually reversed. Coining an Areas value nothing else in your docs/adr directory already uses now asks for your explicit confirmation first, so a typo does not quietly start a new label on its own.
    • Reversing a decision no longer means editing the old record. Point a new ADR's Supersedes: field at the one it replaces; the old record's own Status and Superseded by: fields pick up the link. Its text stays as written — history, not something the new decision rewrites — and the generated index shows the pointer from both records.
    • A shape check for your own decision records. new-adr and new-rfc bundle a script that reads every record's metadata block and reports anything missing, unmatched, or shaped wrong, over the whole directory in one pass rather than stopping at the first problem.
    • Correcting an accepted decision has one place to write it. Add a dated entry under ## Errata instead of editing the decision itself; entries are only ever added, never rewritten or removed.
    Release notes for governance-extras 0.11.0
  9. core 2.26.13

    • Your agent decides where an unsettled assumption belongs. While drafting a spec, it surfaces the assumptions it is making and checks each one before filing it. Some cannot be settled at that point — what an existing helper really does, what a generated file actually contains, what a check truly proves. Each of those is now placed by a rule rather than written down as-is. The rule lives in the new-spec skill's assumptions step, under the anchor load-bearing-claim-routing; it has one home, and this entry does not restate it.
    Release notes for core 2.26.13
  10. core 2.26.12

    • The spec checker now notices when a criterion was reworded and its assertions were not. It could already do this, but only if you knew to hand it a revision to compare against. Without one it said nothing and reported a clean run, so the check was there and almost never ran. It now works out what to compare against on its own — the point your branch left the default branch. Nothing new can fail your build: this check describes what it found and never sets the exit code. Pass --no-since if you want it left alone.
    Release notes for core 2.26.12
  11. core 2.26.11

    • Your agent now reads one conventions file instead of two. The seeded AGENTS.md was a short file that pointed at a much longer docs/CONVENTIONS.md for the rules that actually govern work. Two subagents loaded that longer file in full on every dispatch — roughly 21,900 tokens of context spent before either had read your code. AGENTS.md now states the rules an agent needs to start work: the commit format, the four pull-request questions, the privacy rule, how changes get scoped, when to confirm before a destructive step, and what to do when documented guidance and code disagree. Nothing was dropped to make it fit — the rest moved to whichever artifact already owned it, so the answer is in the guide, skill or architecture document you would have reached for anyway.
    • A new `docs/README.md` tells you what belongs where. Installing the pack gave you four documentation directories and nothing explaining which one a new document goes in. The map names each area, what belongs there, and its lifecycle class — living, frozen, or governance — and it carries a row for you to extend when you add an area of your own. The seeded AGENTS.md routes to it, so an agent entering your repository has a way into your documentation rather than a dead link.
    • The seed stopped offering you sections it already has. Its trailing comment listed Documentation, Security considerations and Scoped instructions as guidance to add once you had a reason. All three are now real sections, so the comment no longer suggests adding what you have. Repository structure is still offered, because the seed still does not carry it.
    Release notes for core 2.26.11
  12. experience-design 2.0.5

    • Four design skills now write where you point them. creative-direction, design-principles, information-architecture and design-system each declare one canonical target under the [design] output_dir you set in agentbundle-layout.toml. Before this release design-principles wrote to a fixed docs/design/principles/... path that ignored your configuration, information-architecture used a location no skill declared, creative-direction named none at all, and design-system produced no file — it now writes a token taxonomy your frontend work can read instead of re-deriving tokens every session.
    • Treat the pack's confinement as a strong default, not a boundary. Each of the four is instructed, before writing, to state the approved output directory, the file it read that value from, and the target path it composed. One full run was captured against the shipped wording — creative-direction, which stated all three — so this is a measured instruction for that skill and an unobserved one for the other three. The check that keeps a write inside that directory is an instruction the agent has to carry out, not something the pack enforces. Against a target reached through a symlink it was skipped in 2 of 8 observed runs, and every skip wrote outside the approved directory. The step was rewritten to require an executed real-path resolution and has refused on every run observed since, but a skipped check still leaves no trace: the file exists and looks ordinary. If you need a guarantee rather than a strong default, enforce confinement outside the agent — in the filesystem, or in a tool that refuses the write.
    • The how-to guides now say what each skill actually does. Nineteen steps published a "where it lands" path. Eight named a file the skill never writes, and several sent you to an aesthetic/ folder nothing produces. Every step now gives either the path its skill writes or a plain statement that it writes no artifact, so you stop waiting for a file that was never coming.
    Release notes for experience-design 2.0.5
  13. core 2.26.10

    • Your loop no longer halts when the same findings come back. It tells you and keeps going, bounded by the iteration cap. The stop it replaced never fired: the signal it read is equality over a fingerprint that carries a finding's position, so any repair that moved a finding made the round look new.
    Release notes for core 2.26.10
  14. core 2.26.9

    • Your implementer looks for what you already have before it writes something new. Hand it a task whose best answer is a helper sitting elsewhere in your repository and it now finds that helper and uses it, instead of writing a second copy of the same logic a module away. When it finds something that only partly fits, its report names that helper too, so a near-miss is visible to you rather than silently passed over.
    • A plan that asks for more structure than the job needs no longer gets built as written. Where a lighter route satisfies the task's own "done" check, the implementer takes it and records the swap for you to see, rather than faithfully building a configuration class and a new module to do the work of one function. Structure you genuinely need survives: when several callers really do need different settings, it still builds the shared piece.
    • The loop is now asked to weigh each addition it declines against a stated rule. Its "tempted to add, chose against" note asks for the "Cut before adding" step behind each line, so the reasoning sits against a written rule rather than a one-off justification, and where no step covers the call — an accepted requirement or a safety control forbids it — it is asked to say that instead of fitting a rule to it after the fact. This one is guidance the note requests rather than a check that enforces it, so read the notes rather than relying on them.
    Release notes for core 2.26.9
  15. core 2.26.8

    • A plan that names a task you never wrote no longer runs in the wrong order. loop-cohort schedule used to drop a Depends on: entry pointing at a task the plan did not contain — no warning, no error. The dependency edge vanished, the tasks collapsed into one wave, and because gates run per wave, the gate run collapsed with them. schedule now stops, names every offending task->dependency pair, and writes no state, so you fix the plan instead of discovering the wrong order later.
    Release notes for core 2.26.8
  16. agentbundle 0.47.0

    • Sending your work-loop telemetry no longer needs `agentbundle` installed to build the command. jsonl-otlp-export reads [telemetry] from your repository and your user agentbundle-layout.toml itself, through its own --config and --user-config, so anything that can run a command can start an export — a hook included. Where you put your settings, and the rule that a repository value wins setting by setting, have not changed.
    Release notes for agentbundle 0.47.0
  17. core 2.26.5

    • Your work-loop runs can now be watched in an observability backend. Install jsonl-otlp-exporter, point it at your own OpenTelemetry Collector, and each phase change arrives as a log record — how long the phase took, which gate decided what, and how close the run is to its retry budgets. It is off until you configure an endpoint, and the thing that sends is a separate distribution you install on purpose, so a catalogue install alone can never transmit.
    • What would be sent is written down before you turn it on. The how-to guide names the file that is read, the records that leave, the fields that may go, and the things a pack cannot see at all — your prompts, the model's replies, and token counts.
    Release notes for core 2.26.5
  18. agentbundle 0.46.0

    • A self-hosted catalogue can now be recreated from its recorded recipe. A repeat catalogue init --preset self-hosted keeps the recorded catalogue identity and pack and profile selections unless you explicitly replace them.
    Release notes for agentbundle 0.46.0
  19. agentbundle 0.45.0

    • `agentbundle` can now work out where to send your loop telemetry. A new resolver reads your repository and personal layout files and returns the exact arguments for the separately installed sender. Repository settings win per setting, because sending data off the machine is a team decision rather than a personal one — the opposite of how personal research settings resolve.
    • `catalogue lint` now tells you when an optional tool a pack wants is not installed. It names the package and exits 0. It never installs anything.
    Release notes for agentbundle 0.45.0
Back to the top