Tautline 0.9.9

Fixed

• Publishing to npm failed again right after the 0.9.8 fix landed, this time with
  ENEEDAUTH. npm's OIDC trusted-publishing exchange mints a short-lived credential
  only when the published package's repository.url matches the workflow's identity
  claim, and npm compares that field case-sensitively. The generated package manifest's
  homepage, repository.url and bugs fields all read the lowercase tautlines,
  but GitHub's canonical owner is Tautlines (capital T), so the comparison never
  matched, no token was minted, and npm fell back to demanding an interactive login.
  These fields are now generated from GitHub's exact canonical casing, and a guard
  test pins it going forward. Publishing to PyPI, which does not compare this field
  case-sensitively, was never affected.

Full changelog: https://github.com/tautlines/tautline/blob/main/CHANGELOG.md

Tautline 0.9.8

Fixed

• Publishing to npm never authenticated, so no release could reach npm. The
  publish workflow held no secrets by design, yet still told npm to read an
  authentication token from the environment. No such token existed, so npm sent
  an empty credential rather than exchanging its OIDC identity, and the registry
  rejected every attempt with a 404. The workflow no longer configures a registry
  token in any form, and npm authenticates over OIDC Trusted Publishing as it was
  always meant to. Publishing to PyPI was never affected.
• release-tail could not resume once it had tagged a release. It compared the
  tag's object identifier against the commit it had just pushed, but an annotated
  tag's reference names a tag object rather than a commit, so the two never
  matched and the command refused to continue, reporting a correctly placed tag
  as pointing somewhere else. Tags are now resolved to their commit before the
  comparison. A tag that genuinely points at a different commit is still refused:
  a published tag is never moved.

Full changelog: https://github.com/tautlines/tautline/blob/main/CHANGELOG.md

Tautline 0.9.7

Added

• release-tail runs the whole release tail as one command: export, public-mirror
  commit, tag, GitHub Release, registry publish, and drift verification, printing
  evidence for each step. --dry-run prints the complete plan and changes nothing,
  and --skip-registry stops at a draft Release so no publish fires. Resuming needs
  no flag: rerunning the command continues a partially-completed tail without
  repeating finished steps or publishing twice.
• release-drift-check compares the version held by the repository, npm, and PyPI
  and exits non-zero when they disagree. It runs after a publish and on a daily
  schedule, so a stale registry is caught within a day rather than months later.
• registry-package generates the npm and PyPI pointer-package metadata from a
  single source, so what the registries say can no longer drift from what the
  project ships.
• Publish workflows for npm and PyPI that authenticate with OIDC Trusted
  Publishing and contain no secrets: the registry mints a short-lived
  credential from the workflow's identity token, so there is no API token to
  create, paste, rotate, or leak.

Changed

• The public mirror is only ever fast-forwarded. The release tail never
  force-pushes it and never rewrites its history, so existing clones stay valid.
• Because a registry publish cannot be undone, each publish workflow first asks
  the registry whether the target version already exists, does nothing when it
  does, and fails closed rather than publishing blind if the registry cannot be
  read.

Security

• Registry publishing no longer involves a stored credential of any kind. Note
  that this requires the maintainer to configure Trusted Publishing once on npm
  and on PyPI, binding each to this repository and to the publish workflow
  filenames. Until that one-time configuration is done, the publish workflows
  fail closed; they never fall back to a token. The workflow filenames are part
  of the trust relationship, so renaming one breaks it. The bootstrap order and
  the registry configuration steps are documented in the release-engineering
  reference.

Full changelog: https://github.com/tautlines/tautline/blob/main/CHANGELOG.md

0.9.6 — public-surface scrub, docs truth pass, plugin marketplace

[0.9.6] - 2026-07-13

Added

• A regression test now freezes the project's line-length lint exclusion (E501)
  at its current hit count, so the previously-unbounded exclusion cannot grow
  further. Lowering the pinned count remains a manual follow-up as overlong
  lines are cleaned up over time.

[0.9.5] - 2026-07-12

Added

• Claude Code plugin marketplace manifest (.claude-plugin/marketplace.json), so
  /plugin marketplace add tautlines/tautline offers tautline-core and
  tautline-ops directly from the repository. The README documents the install
  flow.
• The quickstart names the shell activation and PATH step that the CLI install
  depends on, so a fresh clone reaches a working tautline command without
  guesswork.

Changed

• TERMS.md now describes the auto-update trust model that actually ships rather
  than a pre-launch target: install-cli pins the update source to the commit it
  installed from by default, --update-policy signed verifies the upstream commit
  signature against a trusted key, and both policies fail closed. Baking
  --dangerously-skip-permissions into a launcher is refused unless one of them is
  in effect.
• SECURITY.md states the supply-chain posture that actually ships. It opens by
  noting the repository is public with published releases, and its trust-posture
  section separates what exists from what does not: the commit-level trust gate on
  every auto-update re-exec is real and fails closed, but the current releases carry
  no checksum manifest and the published release tags are not signed.
  cut-release can compute a SHA-256 manifest and can create a signed tag with the
  right flags, and that capability is now described as a capability rather than as
  something an adopter can go and verify against today.
• SECURITY.md and TERMS.md now note that --update-policy signed applies to an
  upstream you control and sign. The canonical upstream does not sign its commits
  yet, so a signed policy pointed at it refuses every update (fail-closed, with no
  upstream fix available to the adopter); pinned, the install default, is the
  working lever against it. Signing the canonical upstream is listed as a roadmap
  item.
• Public documentation no longer points at maintainer-only paths that a reader of
  this repository cannot open; those references now name the maintainer repository
  or its backlog in prose instead. The render-adapters deprecation warning for the
  legacy goalTracker adapter key drops its pointer to a maintainer-only design
  document and keeps the actionable instruction (migrate to backlogProvider).
• ROADMAP.md speaks of the public repository in the present tense — its work items
  are tracked as issues there and are now backlinked — and its "Recently shipped"
  section is current through the 0.9.x line.
• ROADMAP.md retitles the near-term section to 0.9.x instead of naming a fixed
  0.9.0 target, and states the compatibility sunset explicitly: the legacy
  minervit-methodology launcher name, MINERVIT_* environment fallbacks, and the
  .minervit-ai-delivery.json marker stay supported through 0.x and are removed in
  1.0.
• The renderer-ci workflow accepts workflow_dispatch, so its default-branch badge
  can render a status.

[0.9.4] - 2026-07-12

Changed

• Public-surface scrub: the changelog and the startup-remediation reference no
  longer carry private-tracker issue numbers, incident dates, or internal
  backlog/archive paths; the affected passages now describe the same behavior
  and follow-up tracking in maintainer-neutral terms. A stray internal
  codename was dropped from a .gitignore comment.
• The MakerKit community example (examples/community-skills/makerkit-implementation)
  is fully de-identified: the internal example codename is gone from its
  filename and headings, and exact kit/dependency version pins are replaced
  with relative phrasing (the kit's previous and current minor versions). The
  Stripe and Better Auth teaching patterns are unchanged.
• The internal release-update delivery ledger is excluded from the public
  release export, alongside the repo's other maintainer-only records. The
  release-update accountability gate now evaluates against the maintainer's
  source repository instead of the exported tree, so public-release-export
  stays gated on release-update delivery rather than tripping on the ledger's
  absence from the export.

[0.9.3] - 2026-07-12

Changed

• Brand copy sweep: live reader-facing docs teach the tautline CLI, the
  tautlines/tautline-dev repository, and the ~/.config/tautline/tautline.env
  config surface; a guard test bans the retired "minervit methodology" brand on
  those surfaces. Documentation and test expectations only — no runtime changes.

[0.9.2] - 2026-07-12

Changed

• Config surface rebrand: the CLI, emitted shims, launchers, and git hooks read
  ~/.config/tautline/tautline.env first (legacy ~/.config/minervit/methodology.env
  kept as a byte-identical mirror and fallback); TAUTLINE_METHODOLOGY_REPO and
  TAUTLINE_CLAUDE_AUTOCOMPACT_PCT aliases are emitted, and lane/codex child
  environments dual-write both families. Re-exec tokens move to
  ~/.config/tautline/reexec-tokens. Trust configuration (update policy and pins)
  keeps its 0.9.1 names and semantics: install-cli pins at the installing HEAD and
  update-repin afterward widens trust; update-repin keeps both config surfaces'
  pins in step. TAUTLINE trust aliases and pin-set preservation ship separately as a
  focused security change.
• Held-update banners defer to the active trust policy's remedy in the hold detail
  (lands the deferred 0.9.1 R2 finding).

0.9.1 — no-dead-ends launch gates

[0.9.1] - 2026-07-11

Changed

• No dead ends at launch: a trust-policy hold on an available update now reports
  held (exit 0) and launch continues on the trusted retained checkout with the
  repair command printed alongside — provided the retained head itself passes the
  active trust policy (otherwise still fail-closed). Generated Claude launchers
  print an exact executable remedy with every gate failure and, when interactive,
  start a Claude repair session instead of a bare refusal
  (TAUTLINE_NO_REPAIR_SESSION=1 opts out). The checkout still never advances to
  unverified code.
• Rebrand identity: the framework's dev repository moved to tautlines/tautline-dev
  (renamed + transferred from minervit/minervit-ai-delivery-methodology; GitHub serves
  redirects). The self-adapter and METHODOLOGY_REPO_SLUG now record the new slug; the
  legacy slug stays accepted everywhere the framework identifies its own repo, so
  unconverted checkouts keep starting during the transition.

0.9.0 — sanitized instrumentation telemetry

[0.9.0] - 2026-07-11

Sanitized instrumentation replaces narrative session-journal publication. A
session journal narrates the adopter's product work, so it can never be proven
safe to publish; 0.9.0 disables narrative publication entirely and introduces a
closed-vocabulary instrumentation record with zero product-information capacity
as the only session evidence that can reach a remote.

Added

• Sanitized instrumentation record and CLI (experimental):
  publish-instrumentation-record recomputes a closed-vocabulary record
  (enumerated event codes plus numbers, no repo/branch/project/path/freeform
  fields) from the local observability event log and publishes it to the
  constant tautline-telemetry-archive branch via a hardened push path — pinned
  adopter-neutral commit identity/date, whole-branch fail-closed hygiene,
  closed-set commit-object parse, byte-compare readback, branch-tip ancestry
  guard, and recompute-at-publish so a tampered preview cannot influence what
  publishes. prepare-instrumentation-record and
  validate-instrumentation-record round out the surface.
• Additive instrumentation adapter key (experimental):
  {enabled (default false), cadence (default milestone)}. enabled alone
  permits publishing; cadence gates only boundary prompting.
  instrumentation.enabled requires observabilityEvents.enabled, and unknown
  instrumentation.* subkeys are rejected (remote metadata is a fixed constant).
• docs/reference/instrumentation.md documenting the record shape, guarantees,
  and the explicit threat model; the generated
  methodology/instrumentation-schema.json is registered as public-contract
  surface.

Changed

• The session-journal opt-in hint, generated-adapter guidance, goal kickoff
  prompt, and lane-start/status lines now describe the local-only reality and
  point at instrumentation for upstream contribution.

Deprecated

• publish-session-journal and publish-pending-session-journals are deprecated
  (removal >= 1.0.0), replaced by publish-instrumentation-record.

Security

• Narrative session-journal publication is disabled: both publish commands refuse
  for every adapter in every mode (--commit --push, bare --file,
  --allow-release-checkout-write). No new narrative content can reach any remote
  from any adapter; journals remain local-only evidence. This invokes a new
  deprecation security-exception clause allowing a stable surface confirmed to
  expose adopter data to a remote to be hard-disabled ahead of its deprecation
  window with a required migration note and named replacement.