v0.12.0 — ticket import into /story-time, status write-back on /go-live

One loop ships here: ticket-import, released through PR #57.

Added

• Starting a new piece of work (/story-time) can now begin from a real GitHub issue number instead of retyping its title and description by hand — pass the issue number and the tool fetches it, then still asks all the same clarifying questions it always has.
• Teams that track work in GitHub Issues can opt in, once, to having a finished release post a single status update back to the issue it came from — so the tracker stops sitting silently "open" once the work is actually done, approved, or handed off.

Changed

• Nothing changes in how existing work is planned, reviewed or released unless a maintainer actively passes an issue number or opts a project into status updates — every other project sees identical behavior to before.

Fixed

• Nothing — this release adds capability, it does not correct a defect.

Honestly, what's not proven yet: the failure-handling path (missing or unreachable gh command) and the "no ticket on file" skip path are confirmed only by reading the code, not by triggering them live; and neither the import half nor the status-update half has yet been exercised on a project outside this one. Full detail: docs/status.md.

Full trail: .spark/ticket-import/ · Full Changelog: v0.11.0...v0.12.0

v0.11.0 — /charter as the start: kickoff interview, discovery pass, shared Project Context

One loop ships here: project-kickoff, released through PR #50 — plus a rewritten README with a narrated demo.

Added

• /charter is now the natural first step on a brand-new project: on an empty repo it asks a short set of hard questions up front (who it's for, what they do today without it, the smallest version that would help, how you'll know it's working, your stack preference, any hard constraints, and what to build first) and drafts a starting constitution and first slice from your answers — offered for your go before anything else runs.
• On a project that already has code, /charter now runs a short discovery pass — reading your README, any CLAUDE.md, and existing specs — and writes back a bounded project summary (who it's for, the stack, how to run it, conventions, known pain points) that you review and correct once.
• The Product Owner and Engineering Manager now start each new feature from that shared project summary instead of re-reading the whole codebase from scratch every time, falling back to a fresh read only where the feature actually touches that area or the recorded picture is missing or in doubt.
• A 100-second narrated demo of one real 47-minute session — /spark to /go-live, including QA in a real browser — now plays right at the top of the README.

Changed

• The README is a third of its former length and leads with what the loop produces: a /spark walkthrough, the .spark/ trail it leaves, two commands to install, and two real, complete examples to read (steamcore, an ESP32 console built from scratch with aSPARK, and this repository itself). It opens with a short "Start here" pointer to /charter.
• Nothing was dropped: the detailed evidence moved to docs/status.md, the companion and optional-tools account to docs/family.md, and the repository guide to docs/repo-layout.md.

Fixed

• Starting /spark or /next-steps on a project with no constitution used to leave you stuck between the two — each behaved as if the other had already set things up. Both now recommend /charter first, while still letting you skip it and continue exactly as before.

Full trail: .spark/project-kickoff/. The previous minor, v0.10.0, is released alongside this one.

v0.10.0 — One lens registry: every active check runs in every phase it claims

One loop ships here: lens-dispatch-registry, released through PR #49.

Changed

• Setting up a project (/charter) now offers every accessibility-style option it actually knows about, sourced from the same list the rest of the loop uses, instead of a fixed short list that could quietly leave a real option out.
• Design review, code review and testing now always pick up every check a project has turned on — adding a new check in the future takes effect everywhere at once, with no separate update needed to make it actually run.

Fixed

• The accessibility check (added in 0.9.0) could be turned on for a project yet still silently not run during design review and testing. It now runs every time, exactly as project setup promised.

Nothing net-new to turn on — no new lens, no new command.

Full trail: .spark/lens-dispatch-registry/ — spec, plan, review, QA, release and the evidence for all nine lenses.

v0.9.0 — The accessibility lens: the 9th situational lens

Two loops ship here: accessibility-lens (the minor bump) and companion-offer.

A note on 0.8.2: companion-offer prepared a 0.8.2 patch bump on its own branch, but accessibility-lens merged first and took main to 0.9.0; the conflict resolution kept 0.9.0. No commit on main ever declared 0.8.2, so no such tag exists — that loop's changes are released here instead.

Added

• A new accessibility lens (lenses/accessibility.md, the 9th) is available for any project that has to meet an accessibility standard — WCAG, ADA, EAA, Section 508 — regardless of what kind of project it is, not just websites. Once turned on, it grounds a real, measurable accessibility target at spec time, then re-checks it during design, during implementation, at code review, and once more with a hands-on keyboard-only pass before ship. It is the first lens to own an Act-phase check.
• README.md now documents the second optional companion, aspark-guard — what it does, that it's optional, and the exact command to install it yourself.

Changed

• README.md and tools/README.md now distinguish three kinds of optional extras — a lens the project profile turns on, a tool a ceremony detects automatically, and a companion plugin you install yourself — so it's clear at a glance which one applies to something new you're considering.
• README.md's status table and ROADMAP.md now both account for aspark-guard, with an honest, qualified maturity note (substantial self-tested evidence from its own author; not yet independently verified by this project; never exercised through a third party's own feature loop) rather than a bare "proven" or "unproven" label.
• seo and ux's existing "this doubles as the accessibility check" notes now point at the new lens by name instead of a vague phrase.

Fixed

• Nothing was previously broken. The lens closes a coverage gap: until now, only a one-time design-stage review touched accessibility, and nothing afterward re-checked it. The aspark-guard documentation closes a gap of a different kind — the companion plugin was shipped and installable but named in no tracked doc.

Known limitation, disclosed rather than hidden

• The accessibility lens is not fully wired. Turning it on today still requires a maintainer to hand-edit two of the loop's own instruction files before its design-review and hands-on-testing checks actually run — that dispatch isn't automatic for this 9th lens the way it is for the first eight. Five sites are affected; the gap was recorded refuted-with-finding and independently re-verified four times across the loop (plan, two review rounds, QA) with no drift. It is written up in README.md's status table and lenses/README.md, and queued as follow-up work — not silently shipped as if it already worked end to end.

---

Full gate trail and evidence: .spark/accessibility-lens/, .spark/companion-offer/. Merged via #47 and #46.

v0.8.1 — Remove the metrics counter, publish the method instead

Tagged retroactively on 2026-09-16 — this version shipped to main on 2026-09-12 but was never tagged at the time. It covers two loops: metrics-script-removal and the situational-lenses verification sweep.

Added

• docs/metrics.md now prints the four python3 commands plus the four rules for combining results across machines — everything that produced every published figure. With only a clone of this repository you can recount all of them yourself and compare against the published numbers.
• README's project status carries a dated snapshot block: the numeric table is still there, labelled as evidence taken on a date and not updated since.

Changed

• Installing aSPARK no longer puts any executable file in your plugin cache. The 32 KB Python counter and the whole scripts/ directory are gone; what you receive is Markdown and JSON and nothing else.
• The dogfooding headline no longer leads with a count that goes stale. It now says what the committed reports contain and that anyone can recount them — a claim that stays true as time passes.
• The reports directory describes itself honestly: a closed, dated snapshot, with the "contribute your own report" workflow removed, because nothing here can produce another report.
• The project's own constitution matches the repository again — four edits close the standing exception for tracked executable code that was opened earlier the same day.
• The README's project-status table now describes what was actually checked for situational lenses — verified against this project itself and three real external projects' completed work — instead of an unverified claim.

Fixed

• Two places where a real external project's private, non-public name briefly appeared in this repository's history were found and removed before anything was shared outside that machine; nothing that leaked reached GitHub.
• A counting method that could report "zero problems found" when the real state was "nothing was actually checked" was replaced with one that checks properly in every case — it still finds the same problems it always should have.

Removed — what you lose, with nothing back

• The figures can never be refreshed from inside this repository again. They are permanently checkable and permanently frozen at their snapshot date; producing a newer one would need a tool that no longer lives here.
• The "count your own projects" invitation is gone, with no replacement. There is no external home for that tool today, so pointing you anywhere would be a false promise rather than a redirect.

Known gaps, disclosed rather than hidden

• One acceptance criterion was never performed: that the installed plugin, refreshed from the branch, contains no Python file. The repository-side evidence holds (no tracked .py, a clean clone with zero executables), but the install refresh itself was blocked by the environment's permission layer.
• Three findings from the situational-lenses sweep are routed, not fixed here (verify-only by design): a gap where one feature's quality checks get applied under the wrong checklist in roughly 3 of 4 projects surveyed; a place where adding a future checklist would require editing more than the one file it is supposed to be limited to; and two kinds of project (public websites, API services) that nobody has yet run this tool on, so those checks remain genuinely unproven rather than confirmed.

---

Full gate trail and evidence: .spark/metrics-script-removal/, .spark/situational-lenses/. Merged via #42 and #43.

v0.8.0 — Right-sizing: declare a project's QA method once in the constitution

Added

• A project with no browser-observable surface can declare its QA method once, so the QA step proceeds by that method automatically instead of asking the same override question on every feature.
• A release for such a project now describes QA as having run by that declared method — a settled project fact — rather than reporting a one-off exception granted for that release.

Changed

• A later review or QA pass can now cite a fact an earlier pass in the same feature already established, instead of re-deriving it from scratch — except when verifying a fix to that exact fact, verifying a required acceptance criterion, when the earlier pass flagged the fact as unverified, or when there's a concrete reason to doubt it; those cases still get a fresh check.
• On a project with no such declaration (every project's default today, unchanged), or where the declaration is missing a piece or names a method the session genuinely can't perform, the QA step behaves exactly as before — same question, nothing silently skipped.

Fixed

• The QA-method override that had to be renegotiated by hand on four consecutive features no longer needs repeating once declared.

Stated plainly, not hidden: four of the files carrying this release's QA-declaration wording — skills/demo-day/SKILL.md, skills/spark/SKILL.md, skills/go-live/SKILL.md, agents/release-manager.md — remain not-verified-live in this loop's own testing; the nested session needed to exercise them could not authenticate in this environment, reproduced in all 8 QA rounds. Recorded as an accepted, environment-caused gap, not a defect, and still true as of this release. This change makes no claim about line, token or cost savings, and no claim that the result generalizes beyond this project.

---

Full gate trail and evidence: .spark/right-sizing/ (spec, plan, review, qa, release, evidence). Merged via #31.

v0.6.0 — Lean artifacts: a fixed address on every report

Added

Every review, QA, spec, plan and release report now opens with a short Handoff block right at the top — status, a one-line verdict, what (if anything) is still open, which section has the final ruling, and what wins if the block and the rest of the report ever disagree. You can tell whether a report is done and what's left without reading the whole thing.

Changed

The team members and ceremonies that act on a previous report — the Reviewer doing a re-review, /increment closing out findings, /go-live checking its two release gates, /next-steps scanning for open items across features — now read that new block first, and only read further when they specifically need to (for example, verifying a fix was actually made, or working out a genuine disagreement between the block and the report). Reports written before this change keep working exactly as they did before; nothing about reading them changes.

Fixed

Nothing — this release adds a new capability rather than fixing a defect. No token or byte saving is claimed anywhere: the new block adds lines, it does not shrink anything.

---

Full gate trail and evidence: .spark/lean-artifacts/ (spec, plan, review, qa, release, evidence). Merged via #22.

aSPARK v0.4.0 - Graph-gates: an optional accelerant for the loop

Ceremonies that run /sprint-plan, /peer-review or /demo-day now notice an
installed, built aspark-graph on their own and use it to scope their work
faster - no install step, no flag, no config file. Absent, nothing
changes. Present but stale, unbuilt, or silent on a query, the ceremony
says so once and falls back to reading the project by hand, exactly as
before.

Plans can now name, per task, which files it touches (a 'files:' note in
the Definition of Done) - added only when knowable up front.

Six acceptance criteria ship as documented partials rather than full
passes, each with a named, structural reason; none is a broken feature,
and every one degrades safely to prior behavior.

aSPARK v0.3.1 — Propose the next feature

Adds /next-steps: when there's no idea in hand, the Product Owner surveys
the project's current state - shipped features from git history, in-flight
and stalled work from .spark/ artifact statuses (including open review/QA
findings), and the constitution's Product Principles - and proposes one
concrete next feature with a ranked alternative or two.

Advisory only: nothing is written to .spark/ and nothing needs approval.
The output hands straight into /story-time or /spark once the user picks
(or overrides with their own idea). /spark itself now points here instead
of guessing when there's no feature left to resume.

aSPARK v0.3.0 — situational lenses

Adds a situational layer on top of the SPARK loop: the process now adapts to what kind of software you're building, so relevant concerns get scrutinized and irrelevant ones stay quiet. Fully backward compatible — a project without a profile behaves exactly as before, because no lens is ever applied without one.

✨ New

• Project profile — the constitution gains a Project Profile & Active Lenses section recording the project's type (website, web-app, api, cli, library) and its characteristics (handles-auth, is-public, handles-payments, handles-pii, has-database, is-multilingual). The Facilitator grounds both in the repo's real signals with evidence; the user confirms. A project can be several types and carry several characteristics.
• Eight lenses — situational checklists the existing agents apply in the phases they own. Lenses are knowledge, not roles: no new agents, no new ceremonies.
  • seo — indexability, SSR vs client-only render, per-page metadata, structured data, Core Web Vitals
  • ux — flow efficiency, empty/loading/error/success states, forms, responsive & touch
  • api — resource design, error-envelope consistency, versioning & breaking-change detection, auth surface
  • cli — help clarity, stdout/stderr discipline, exit codes, safety flags
  • library — public API surface, semver & deprecation discipline, packaging & footprint
  • security — header/transport hardening, auth lifecycle, authz matrix, supply chain, PII/privacy
  • i18n — externalized strings, locale-aware formatting, text-expansion & RTL layout
  • data — migration safety, integrity & transactions, indexing at scale, retention & recovery
• Two trigger axes — a lens activates from the type (seo←website, ux←web-app, api←api, cli←cli, library←library) or from a characteristic (security←auth/public/payments/PII, i18n←multilingual, data←database). Security is a property of what software does with data, not of its shape — so it binds to behavior, not type.
• Traceability, not assertion — a lens concern becomes a measurable NFR- in Specify and is verified downstream under the same ID, riding the existing gates. Nothing is raised in one phase and quietly dropped in the next.
• Constitution as single source of truth — the profile is the only place a lens is switched on, so phases can't drift from one another. With no constitution, a phase gives a one-line nudge toward /charter and applies nothing.
• Lens load flag — no cap on stacking; at 4+ active lenses the profile flags the elevated load, because visibility is the throttle.
• Add-a-file extensibility — a new concern is a new file in lenses/ plus a profile entry. Skills pass active lens paths generically, so no agent or skill is rewritten.

🔧 Changed

• Templates: constitution.md gains the Project Profile & Active Lenses section and the load flag; spec.md notes that active-lens concerns land as measurable NFRs.
• Agents: facilitator detects type + characteristics and derives active lenses; product-owner captures lens concerns as NFRs; designer applies ux/seo/i18n; reviewer verifies each lens's review slice in the diff; qa-tester verifies the browser-observable slice (ux, seo, security, i18n).
• Skills: /charter surfaces the profile and load as the user's decision; /story-time, /look-and-feel, /peer-review, /demo-day resolve active lenses from the constitution and pass their paths; /spark nudges toward /charter when no profile exists.
• Docs: docs/workflow.md gains a Situational Concerns section; new lenses/README.md documents the lens contract, both trigger axes, and the detection signals.

✅ Validation

• Dogfooded through aSPARK's own loop. The feature was run through /story-time before release (.spark/situational-lenses/spec.md). The Product Owner's Clarify pass caught two real defects in the first cut, both fixed before this shipped:
  • the no-constitution fallback was duplicated across three skills and re-derived lens logic per phase (drift-prone) — now nudge-only;
  • nothing surfaced when many lenses stack — now flagged at 4+.
• All eight lens files conform to the documented contract (frontmatter, per-phase owner map, falsifiable checks only).

⚠️ Known limits (recorded, not papered over)

• Non-UI lenses have no QA surface. api, cli, library and data contribute zero /demo-day checks — the QA phase is browser-shaped and they have no browser to click. Their verification is Specify, Review and the increment's own tests. This is a pre-existing limitation of the loop that the lens layer makes visible rather than hides.
• Lens compliance is instruction-driven. No test enforces that a lens actually fired; a silently-skipped lens looks like a correct N/A. The human gate is the only check.
• The success signal is not yet proven. The feature's own spec defines success as a UI lens firing and being QA-verified on a website plus a Review lens firing and being Review-verified on an api, both under the same NFR-. Neither has been demonstrated by a full loop run yet.

Full changelog: v0.2.0...v0.3.0