@zalom/plastic 2.0.0-alpha.27 → 2.0.0-alpha.29

package/skills/project-creating/references/project-scaffolding.md

@@ -1,97 +0,0 @@
-# Project Scaffolding Templates
-
-Full templates for the artifacts created while spawning a project: the AGENTS.md
-skeleton (Workflow step 4), the tactical mirror intent (step 5), and the
-projects.yml registration block (step 6).
-
-## Table of Contents
-
-- [AGENTS.md skeleton (step 4)](#agentsmd-skeleton-step-4)
-- [Tactical mirror intent (step 5)](#tactical-mirror-intent-step-5)
-- [projects.yml registration block (step 6)](#projectsyml-registration-block-step-6)
-
-## AGENTS.md skeleton (step 4)
-
-Create `AGENTS.md` in the project root with:
-
-```markdown
-# <Project Name> — Agent Instructions
-
-Read `PLASTIC.md` in `~/.plastic/` for the core conventions; deeper doctrine lives in
-the `plastic-conventions` skill's chapters. Follow it exactly.
-
-This file is the operating contract for this project. Any agent entering
-this project reads this file first.
-
-## Global Store
-
-Location: `~/.plastic/`
-Governing intent(s): <list of founding intent IDs with descriptions>
-
-## Decisions
-
-<Copy ALL decisions from founding intent(s)' `## Context > ### Decisions`>
-
-Each decision should include:
-- The decision itself
-- The rationale (why this choice)
-- Date decided
-
-## Project-Specific Rules
-
-<Any rules derived from the decisions — e.g., "Use Minitest, not RSpec",
-"37signals methodology", "sqlite-vec for vector storage">
-```
-
-## Tactical mirror intent (step 5)
-
-Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`:
-
-**Directory:** `~/.plastic/projects/{slug}/store/1--{slug}/`
-**File:** `~/.plastic/projects/{slug}/store/1--{slug}/1--{slug}.md`
-
-```yaml
----
-id: '1'
-intent: "<same description as founding intent>"
-sources: ["global:<founding_intent_ID>"]
-chain: []
-created: <today>
-author: <same as founding intent author>
-tags: [<relevant tags>]
----
-```
-
-Sections:
-- `## Intent` — same as founding intent
-- `## Context` — carry forward relevant Context and Decisions
-- `## Outcome` — (pending)
-- `## Insights` — empty
-- `## Links` — `[[global:<founding_intent_ID>|<founding intent name>]]`
-
-Update the project's `~/.plastic/projects/{slug}/INDEX.md`:
-```markdown
-# Index
-
-## Active
-- [1 — <intent name>](store/1--<slug>/1--<slug>.md) — implementation, from: global:<ID>
-```
-
-**For multi-intent spawning (Hub):**
-- `sources`: `["global:<id1>", "global:<id2>", ...]` — all founding intents
-- All founding intents' decisions merge into AGENTS.md
-- Context carries forward from all founding intents
-
-## projects.yml registration block (step 6)
-
-Read `~/.plastic/projects.yml` and add:
-
-```yaml
-<slug>:
-  path: <full-path>
-  parent: "<founding_intent_ID>"
-  registered: <today>
-  status: active
-```
-
-For Hub-spawned projects, `parent` references the primary founding intent.

package/skills/releasing/SKILL.md

@@ -1,376 +0,0 @@
----
-name: plastic-releasing
-description: Use when merging a feature branch to main and tagging a release, bumping the version, or when the user says "release", "tag", or "ship it"
-user-invocable: true
----
-
-# Releasing
-
-Merge, bump, tag, push. Annotated tags with changelogs. Semantic versioning.
-Project configuration drives the workflow - no hardcoded assumptions.
-
-## Checklist
-
-- [ ] Read project config
-- [ ] All tests pass (or verification skipped per config)
-- [ ] Merge feature branch to main
-- [ ] Bump version in configured version files
-- [ ] Stable-cut guard passes (version files agree, no pre-release suffix; stable/latest cuts only)
-- [ ] Commit version bump
-- [ ] Create annotated tag
-- [ ] Push to remote with tags
-- [ ] Run post-push actions (GitHub release, npm publish, etc.)
-- [ ] Verify release sync (npm dist-tag, GitHub "Latest", git tag all show the new version)
-- [ ] Clean up the intent's worktrees (merge-then-remove)
-- [ ] Complete active intent
-
-## Workflow
-
-### 0. Read Project Config
-
-Before anything else, determine which project we are releasing and load its config.
-
-1. Read `~/.plastic/projects.yml` - find the project whose `path` matches the current working directory.
-2. Extract the project slug (the key under `projects:`).
-3. Read `~/.plastic/projects/{slug}/project.yml` - this contains the `release:` section.
-
-Expected `release:` keys in project.yml:
-
-```yaml
-release:
-  verify: "bin/rails test"              # command to run before release
-  version_file: package.json            # single file containing the version
-  version_files:                        # multiple files (overrides version_file)
-    - package.json                      # list EVERY file carrying the version;
-    - .claude-plugin/plugin.json        # they must all be bumped together or they drift
-    - .claude-plugin/marketplace.json
-  tag_format: "v{{version}}"            # tag naming pattern ({{version}} is replaced)
-  on_green:                             # actions to run after push succeeds
-    - github_release
-    - npm_publish
-  on_complete: commit_and_push          # what to do with the version bump commit
-  on_red: stop                          # what to do if verification fails
-```
-
-**Fallback:** If no project.yml exists or it has no `release:` section, fall back to asking the user for each step - verify command, version files, tag format, and post-push actions.
-
-### 1. Verify Tests Pass
-
-Run the verification command from `release.verify` in project.yml:
-
-```bash
-# Example: release.verify = "ruby -Itest test/*_test.rb"
-<verify-command-from-config>
-```
-
-- If `release.verify` is present: run it. All checks must pass before proceeding.
-- If `release.verify` is absent or empty: skip verification. Log that no verify command is configured.
-- If `release.on_red` is `stop`: abort the release on failure.
-- If `release.on_red` is `fix_and_retry`: ask the user to fix and re-run.
-
-### 2. Determine Version Bump
-
-| Change type | Bump | Example |
-|-------------|------|---------|
-| Breaking changes | Major | 0.x.0 → 1.0.0 |
-| New features | Minor | 0.3.0 → 0.4.0 |
-| Bug fixes only | Patch | 0.4.0 → 0.4.1 |
-
-Pre-1.0: minor bumps for features, patch for fixes. No major until stable.
-
-### 3. Merge Feature Branch
-
-```bash
-git checkout main
-git merge <branch-name> --no-ff -m "feat: merge intent [ID] - [description]"
-```
-
-Always `--no-ff` to preserve branch history in the merge commit.
-
-**Worktree-isolated intents (intent 73c3).** A worktree-delivered intent's code lives on
-`plastic/{id}--{slug}`, merged together with cleanup in step 9, not on a hand-made feature
-branch. Do not delete the worktree before its branch is merged, or the work is lost. For
-the full rationale and the already-merged-by-hand no-op case, read
-`references/promotion-and-tagging.md`.
-
-### 4. Bump Version
-
-**Stable-cut guard.** Before touching any version file for a stable (no pre-release suffix,
-`latest`) cut, run the guard in `scripts/lib/release_guard.rb`:
-
-```ruby
-require "./scripts/lib/release_guard"
-result = ReleaseGuard.check(
-  package_json: "package.json",
-  plugin_json: ".claude-plugin/plugin.json",
-  marketplace_json: ".claude-plugin/marketplace.json",
-  stable: true
-)
-raise "release guard failed: #{result.mismatches} #{result.prerelease_suffix}" unless result.ok?
-```
-
-If it reports a mismatch or a pre-release-suffix violation, stop and resolve it before bumping
-any file. For a beta or alpha cut, pass `stable: false`; only version-file agreement is checked,
-a pre-release suffix is expected. Read `references/release-lines.md` for the stable-line
-guarantees this guard protects.
-
-Determine which files to update from project.yml:
-
-- If `release.version_files` is set: update ALL listed files (they must stay in sync).
-- Else if `release.version_file` is set: update that single file.
-- Else: ask the user which files contain the version.
-
-Update the version string in each file, then commit:
-
-**Cut the CHANGELOG entry.** Before committing, edit `CHANGELOG.md` at the repo root so
-the changelog change rides this same version-bump commit and reaches the tag. Write one
-line in the existing shape:
-
-`` `<version>` - shipped <date>; collected <intent-id> (<one-line summary>) ``
-
-Prepend it as the first bullet under `## Released` (newest-first). If this version was
-sitting under `## Unreleased`, move it out of that section and into `## Released`. Keep
-the line intent-centric narrative (which intents the cut collected and why), NOT commit
-detail: step 5's tag-message changelog and step 7's `gh release create --generate-notes`
-already own the commit-level detail, so do not duplicate it here.
-
-```bash
-git add <version-files> CHANGELOG.md
-git commit -m "chore: bump version to X.Y.Z - [one-line summary]"
-```
-
-### 5. Create Annotated Tag
-
-Read `release.tag_format` from project.yml to determine the tag name:
-
-- If set (e.g. `"v{{version}}"`): replace `{{version}}` with the new version string.
-- If not set: default to `vX.Y.Z`.
-
-Generate the changelog from commits since the last tag:
-
-```bash
-git log $(git describe --tags --abbrev=0)..HEAD --oneline --no-merges | grep -E "^[a-f0-9]+ (feat|fix|refactor):"
-```
-
-Create the tag with a multi-line message:
-
-```bash
-git tag -a <tag-name> -m "<tag-name> - [release name]
-
-- [changelog bullet points from feat/fix/refactor commits]"
-```
-
-### 6. Push
-
-```bash
-git push origin main --tags
-```
-
-### 7. Post-Push Actions
-
-Read `release.on_green` from project.yml. This is a list of actions to run after a successful push. Execute each in order:
-
-#### `github_release`
-
-Create a GitHub release from the tag:
-
-```bash
-gh release create <tag-name> --title "<tag-name> - [release name]" --latest --generate-notes --notes-start-tag <previous-tag>
-```
-
-`--latest` is REQUIRED. Pre-release (alpha/beta) tags are NOT auto-promoted to the "Latest"
-badge by GitHub, so without it the Releases page keeps showing an older version as Latest while
-the newest tag sits below it (a real sync drift we hit on the alpha line). Pass `--latest` on
-every release so the newest one always carries the badge. Do NOT pass `--prerelease` unless you
-specifically want the release hidden from Latest.
-
-For the first release (no previous tag), write notes manually with `--notes "..."` instead.
-
-#### `npm_publish`
-
-Publish the package to npm with the appropriate dist-tag:
-
-```bash
-# Alpha pre-release (version contains -alpha):
-npm publish --access public --tag alpha
-
-# Beta pre-release (version contains -beta):
-npm publish --access public --tag beta
-
-# Stable release (no pre-release suffix, >= 1.0.0):
-npm publish --access public
-```
-
-The dist-tag is derived from the version string in `package.json`:
-- Contains `-alpha` → `--tag alpha`
-- Contains `-beta` → `--tag beta`
-- No pre-release suffix → no `--tag` flag (publishes to `latest`)
-
-#### `npm_publish_workflow`
-
-The tag pushed in step 6 starts the project's publish workflow (GitHub Actions, keyed on the
-workflow file `publish.yml`) instead of a local `npm publish`. The workflow runs with a
-short-lived, per-run OIDC credential, so no npm token exists in this session or on this
-machine.
-
-1. **Confirm a run exists for the tag.** A tag cut from a ref that does not carry the
-   workflow starts no run at all, and silence would read as success:
-
-   ```bash
-   gh run list --workflow publish.yml --limit 5
-   ```
-
-2. **Follow the run.**
-
-   ```bash
-   gh run watch <run-id>
-   ```
-
-3. **Verify the registry, not just the run.** The release is not done until the new version
-   shows up on the expected channel:
-
-   ```bash
-   npm view <package> dist-tags
-   ```
-
-The dist-tag is derived from the version string in `package.json`, the same rule
-`ReleaseGuard.dist_tag` implements:
-
-| Version contains | dist-tag |
-| --- | --- |
-| `-alpha` | `alpha` |
-| `-beta` | `beta` |
-| no pre-release suffix | `latest` |
-
-Do not run `npm whoami` on this path. npm documents that `whoami` does not reflect OIDC
-authentication, so on a workflow-published project it can only mislead.
-
-#### Other values
-
-If `on_green` contains an action not listed above, log it:
-
-```
-[releasing] Action "<action>" is configured but not yet implemented. Skipping.
-```
-
-If `on_green` is empty or absent: skip post-push actions entirely.
-
-#### Verify sync (always, after the post-push actions)
-
-A release is not done until all three surfaces show the SAME newest version. Confirm:
-
-```bash
-npm view <package> dist-tags                      # channel tag (alpha/beta/latest) -> new version
-gh release list --limit 1                         # newest release is the new tag AND marked "Latest"
-git ls-remote --tags origin | grep <tag-name>     # the tag reached the remote
-```
-
-If the GitHub "Latest" badge is on an older tag (the common drift), fix it without re-releasing:
-
-```bash
-gh release edit <tag-name> --latest
-```
-
-### 8. Clean Up the Intent's Worktrees (merge-then-remove)
-
-This step now runs BEFORE step 9's `end-intent` call (intent 188, D7): `scripts/end-intent`
-gained its own step 5 that disarms (releases the worktree, clears `delivery.lock`) as part
-of every close. Its plain-remove shape does not merge, so if `end-intent` ran first on a
-release, its step 5 would remove the worktree WITHOUT merging the code branch first,
-stranding the integrated work (`Worktree.finish` returns early once the worktree block it
-needs is gone, per `worktree.rb`'s own "no-op if nothing was provisioned" contract).
-Running this merge-then-remove step first means the worktree is already gone by the time
-step 9 runs, so `end-intent`'s own disarm becomes a harmless no-op for the worktree
-(nothing left to remove), while for the FIRST time on this path it also clears the delivery
-lock correctly (G5): before intent 188 this path left the lock stranded, exactly the class
-of bug closed by the End-tail enforcement work.
-
-This is the release branch of `plastic-intent-ending`'s Step 5 disarm (`merge: true`), not a
-separate concern: a release is the merge-then-remove path for the intent's worktree (intent
-73c3), so the intent's code branch is merged back into the default branch BEFORE the worktree
-is removed. Drive it through `Worktree.finish` with `merge: true`, which merges the code
-branch, then removes the worktree, and prunes the repo:
-
-```bash
-ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/arm -e \
-  'Worktree.finish(Arm.delivery(intent_dir: "<STORE>/<dir>"), merge: true)'
-```
-
-(The worktree block is derived from `projects.yml` and the intent id, so the one-liner needs
-only the intent directory.)
-
-Honor the worktree-cleanup rule: never leave an orphaned worktree, and run `git worktree
-prune` in the affected repo if you hit a stale reference. For why this is the one place the
-merge-vs-remove policy lands on merge, and the fail-open/idempotent guarantees of `finish`,
-read `references/promotion-and-tagging.md`.
-
-### 9. Complete Active Intent
-
-A release IS a delivery. The active intent that drove this work must be completed as part of the release process. This is NOT optional. The mechanical close (outcome/INDEX/savepoint/commit, AND disarm since intent 188) is `plastic-intent-ending`'s job, not this skill's: run its backing script rather than restating that prose here.
-
-1. Read `~/.plastic/INDEX.md` (or the project's INDEX.md) - find active intent(s) related to this release.
-2. For each active intent being delivered:
-   a. Write a real `outcome.md` (never leave the scaffold placeholder), `disposition: delivered`, referencing the release tag.
-   b. Update `## Insights` with final observations.
-   c. Run the mechanical close (`scripts/end-intent`'s steps 1-5): this stamps the intent file's `## Outcome` summary, moves the INDEX.md line to `## Completed` (dated today, with a rich entry description via `--index-note`), appends the terminal savepoint line, commits the store, and disarms (releases the worktree - already gone from step 8 above - and clears `delivery.lock`), all in one call:
-      ```bash
-      ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
-        --session "$CLAUDE_CODE_SESSION_ID" \
-        --outcome-summary "delivered in <tag-name>: <one-line summary>" \
-        --index-note "<tag-name>, <mode>; <what shipped>; <suite result>"
-      ```
-      A non-zero exit needs attention: 4 means a live foreign session holds the lock (back
-      off), 5 means the code worktree is still dirty (should not happen here, since step 8
-      already removed it; investigate before overriding with `--discard-worktree-changes`),
-      3 means disarm ran but the lock is still present (run `/plastic-doctor check the lock
-      status`).
-   d. Update clusters to show `_(completed)_`.
-
-**If no active intent exists for this release**, that itself is a problem - work happened outside the intent system. Log it and move on, but flag it.
-
-## Release lines and channels
-
-Two lanes get code to a release, on top of the workflow above.
-
-- **Default lane.** Branch, merge to main, cut stable, publish to npm `latest`. This is the
-  workflow in the steps above, unchanged. Use it for additive, suite-verifiable,
-  low-blast-radius work.
-- **Beta-verified lane.** Branch, merge to `beta`, publish to the npm `beta` channel, verify in
-  real use, then merge to main and cut stable. Use it for work that changes operational
-  substrate, or carries data, migration, lock, or state-format risk, or that a hermetic suite
-  cannot fully validate on its own.
-
-**Stable-line guarantees.** An external `latest` user can rely on:
-
-- `main` is always green and releasable; no pending revert awaiting re-land sits on `main`.
-- A stable release carries no pre-release suffix, publishes to `latest`, and the newest release
-  always carries the GitHub "Latest" badge.
-- The three version files always agree, checked by `scripts/lib/release_guard.rb` (see Bump
-  Version above).
-- A stable cut collects only intents that cleared their lane's verification bar.
-- Channel semantics are fixed: `latest` is stable, `beta` is the verification line, `alpha` is
-  experimental.
-
-Read `references/release-lines.md` for the full lane-routing detail, the version-line map, and
-the intent-41 re-land playbook.
-
-## Conventions
-
-- **Annotated tags only** - `git tag -a`, never lightweight tags
-- **Tag format** - driven by `release.tag_format` in project.yml (default: `vX.Y.Z`)
-- **Tag message** - first line: `<tag> - [short name]`, then blank line, then bullet changelog
-- **Commit prefixes** - `feat:`, `fix:`, `refactor:`, `chore:`, `docs:` (conventional commits)
-- **Hyphens, never em-dashes** - in tag names, release titles, and commit messages, use a hyphen (`-`). Never an em-dash.
-- **Latest badge** - always `gh release create --latest`; the newest release must carry GitHub's "Latest" badge.
-- **Version files** - driven by project.yml; list and bump EVERY file carrying the version (they drift otherwise)
-- **Verify sync** - after pushing, confirm npm dist-tag, GitHub "Latest", and the git tag all show the new version
-- **Branch cleanup** - delete merged feature branches: `git branch -d <branch>`
-
-## References
-
-- Read `references/release-lines.md` for the two release lanes, the stable-line guarantees,
-  the version-line map, and the intent-41 re-land playbook before starting any release
-- When promoting a pre-release across channels (alpha to beta, beta to stable) or
-  tagging a historical release retroactively, read `references/promotion-and-tagging.md`
-  for the exact commands and rules first
-- Read `references/deprecations.md` for the full deprecation process, severity levels, deprecations.yml schema, and dismissal rules when adding or managing deprecations

package/skills/releasing/references/deprecations.md

@@ -1,60 +0,0 @@
-# Deprecation Process
-
-When removing a feature, changing a convention, or making a breaking change:
-
-1. Add entry to `deprecations.yml` in the Plastic source root
-2. Set severity: `info` (awareness), `warning` (action needed), `critical` (urgent)
-3. Provide clear migration steps
-4. Set `removal` version at least 2 minor versions ahead
-5. SessionStart hook displays active deprecations automatically
-6. Remove the feature AND the deprecation entry together
-
-## Pre-1.0 removal policy
-
-The numbered process above is the steady-state rule: a deprecation rides until its `removal`
-version, which step 4 sets at least two minors ahead. While Plastic is still pre-1.0 (any
-version below `1.0.0`), one exception applies:
-
-- **Pre-1.0 exception.** Before `1.0.0`, a *satisfied* deprecation (the migration it
-  announced is complete on installed machines) may be removed immediately, rather than waiting
-  for its declared `removal` major. Delete the entry from `deprecations.yml` (leaving
-  `deprecations: []` if it was the last one) the moment the migration is done.
-
-This exception only holds below `1.0.0`. From `1.0.0` onward, the steady-state grace rule
-(step 4, removal at least two minors ahead) governs again, unchanged. The exception narrows
-*when* a satisfied entry may be pulled early during the pre-release line; it does not loosen
-the grace window for the released-product contract.
-
-## Severity Levels
-
-| Severity | When to use | Dismissable? |
-|----------|-------------|--------------|
-| `info` | Upcoming change | Yes |
-| `warning` | Action needed | Yes (re-shown at removal) |
-| `critical` | Urgent/security | Never |
-
-## deprecations.yml Schema
-
-```yaml
-deprecations:
-  - id: unique-slug
-    severity: info | warning | critical
-    summary: "One-line description"
-    migration_steps:
-      - "Step 1"
-      - "Step 2"
-    introduced: "0.9.0"
-    removal: "1.0.0"
-    link: "optional URL"
-```
-
-## Dismissal
-
-Users dismiss by adding the id to `deprecations_dismissed` in `config.yml`:
-
-```yaml
-deprecations_dismissed:
-  - some-deprecated-feature
-```
-
-Critical deprecations and final-version warnings ignore dismissal.

package/skills/releasing/references/promotion-and-tagging.md

@@ -1,70 +0,0 @@
-# Promotion, Retroactive Tagging, and Worktree Merge Rationale
-
-Occasional variant paths off the main release workflow: promoting a pre-release
-across channels, tagging historical releases retroactively, and the deep rationale
-for why the intent's worktree is merged before removal.
-
-## Table of Contents
-
-- [Worktree merge-then-remove rationale](#worktree-merge-then-remove-rationale)
-- [Promotion](#promotion)
-- [Retroactive Tagging](#retroactive-tagging)
-
-## Worktree merge-then-remove rationale
-
-**Worktree-isolated intents (intent 73c3).** When the intent was delivered in a Plastic
-worktree (the delivery lock has a provisioned `worktree` block), its code lives on the branch
-`plastic/{id}--{slug}` inside `<repo>/.claude/worktrees/{id}--{slug}`, not on a hand-made
-feature branch. The merge-then-remove of that worktree is handled together with cleanup in
-Workflow step 9, which merges `plastic/{id}--{slug}` into the default branch BEFORE removing the
-worktree. If you already merged here by hand, step 9 is a clean no-op merge ("Already up to
-date") and proceeds straight to removal. Do not delete the worktree before its branch is
-merged, or the work is lost.
-
-A release is the merge-then-remove path for the intent's worktrees. This is the one place
-the merge-vs-remove policy lands on "merge": the intent's code branch (`plastic/{id}--{slug}`)
-is merged back into the repo's default branch BEFORE the worktree is removed, so the
-integrated work is never lost. (The disarm path in `plastic-auto`, by contrast, is a plain
-remove because no release is merging the branch.)
-
-`Worktree.finish` is fail-open and idempotent: a conflicting merge is aborted and logged (the
-worktree is still removed rather than stranded), and a second call with the block already
-cleared is a no-op.
-
-## Promotion
-
-Promotion is not a CLI flag; there is no `--promote` command. It is a set of steps the
-agent performs during the releasing workflow, reusing the normal release mechanics (version
-bump, tag, GitHub release). For a project on the `npm_publish_workflow` post-push action,
-the tag push itself starts the publish; there is no local publish command to run.
-
-```bash
-# Promote alpha → beta: set version files from -alpha.N to -beta.1, commit, tag, push.
-# The publish workflow reads the new version and publishes to the beta dist-tag.
-
-# Promote beta → stable: strip the pre-release suffix (e.g., 1.0.0-beta.3 → 1.0.0),
-# commit, tag, push. The publish workflow reads the new version and publishes to latest.
-```
-
-A project still on the `npm_publish` action (publishing locally from the session) runs
-`npm publish --access public --tag <channel>` at this point instead, per that action's own
-section in SKILL.md.
-
-**Promotion rules:**
-- Linear only: alpha → beta → stable. Cannot skip channels.
-- Version files are bumped and committed as in a normal release.
-- An annotated tag is created for the promoted version, and the GitHub release is cut
-  as in the normal workflow (`gh release create ... --latest` for stable).
-- To point a channel at an already-published version without republishing, move the
-  dist-tag directly: `npm dist-tag add @zalom/plastic@<version> <channel>`. To move the
-  GitHub "Latest" badge: `gh release edit <tag> --latest`.
-
-## Retroactive Tagging
-
-For repos without prior tags, tag historical releases:
-
-```bash
-git tag -a v0.1.0 <commit-sha> -m "v0.1.0 - [description]"
-```
-
-Use `git log --oneline` to find the right commits (look for version bump commits or major feature merges).