Cut the first signed tag

[ChelseaKR]

The README's status line: Beta. Version 0.1.0, first signed tag not yet cut.

Both measurements are computed, tested, and published against pinned dataset retrievals (FRAP firep25_1 and CAL FIRE DINS, retrieved 2026-08-07), and the figures move only when those retrievals are deliberately refreshed — so there is a stable thing to tag.

A release signing key already exists in this portfolio (tods-validate and gtfs-scorecard sign with it, and tods-validate verifies in CI against a committed allowed_signers), so this needs no new key material.

Note #15 first: ci.yml calls its gates merge-blocking while main has no protection at all.

Imported from the README status line with AI assistance.

[ChelseaKR]

Not doing this one from an agent, deliberately. Recording what is ready and what is not,
so the tag is a decision rather than a rediscovery.

Ready

• pyproject.toml and CITATION.cff both say 0.1.0, so there is nothing to reconcile
  before tagging. CITATION.cff carries date-released: "2026-08-07" with the comment
  "bump on every tagged release", which is the one field that must move with the tag.
• main is green as of 6948cb2, and has been continuously since The audit gate was red on a lockfile pin that no dependency bump would move #53 cleared the
  fast-uri advisory that had verify red on every branch since 2026-09-03.
• git ls-remote --tags origin is empty, so v0.1.0 is unclaimed and there is no stray
  tag to clean up first (unlike tods-validate's v0).
• The measurements are stable to tag against: both retrievals are pinned (FRAP
  firep25_1, DINS POSTFIRE_MASTER_DATA_SHARE, both 2026-08-07) and docs/data/ cards
  plus tests/test_data_cards.py gate their staleness, so the published figures only move
  when a retrieval is deliberately refreshed.

Not ready, and each needs you rather than a PR

1. ci.yml calls its gates merge-blocking; main has no protection at all, and the repo was never registered with the standards program #15's ruleset is still unapplied. This issue already says to note it first, and it
   matters concretely here: .github/rulesets/main.json includes required_signatures.
   Tagging before applying it means the first signed tag sits on a history that was never
   required to be signed, which is most of the value of the tag.
2. The signing key is yours. The portfolio's release key
   (~/.ssh/github-release-signing, used by tods-validate and gtfs-scorecard) is on
   your machine and not reachable from CI or from here. tods-validate also verifies its
   tags in CI against a committed allowed_signers; this repository has no such file, and
   whether to copy that pattern is worth deciding at the same time as the tag.
3. "Published artifact" is an unanswered product question. The README's Release row
   reads "no tag cut, no signed tag, no release workflow, no published artifact". A
   release workflow is buildable, but what it should do is not obvious and is not mine to
   choose: pip-audit already reports perimeter as "Dependency not found on PyPI", the
   package name is generic enough that claiming it is a decision in itself, and PyPI
   publishing needs a trusted-publisher registration only you can make. A GitHub Release
   carrying an sdist and a wheel, with no PyPI at all, is a perfectly good answer for a
   repository whose product is a website; it is just a different answer.

If the answer is "tag it now, artifacts later"

That is a coherent scope, and the whole of it is:

# after applying the ruleset from #15
git -C <repo> tag -s v0.1.0 -m "perimeter 0.1.0"     # with the release key configured
git -C <repo> push origin v0.1.0
gh release create v0.1.0 --verify-tag --notes-from-tag

plus bumping CITATION.cff's date-released to the tag date in the commit before it, and
opening the ## [Unreleased] heading in CHANGELOG.md into a ## [0.1.0] - <date>
section. Those last two are the parts a PR could carry; say the word and the version-bump
commit can be prepared against whatever date you pick, leaving you only the signing.

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Status check, 2026-09-06, so this issue is not read as more blocked than it is.

The disclosure half is now correct and gated. tests/test_release_claims.py reads
git tag --list and holds the declared version against the tags that actually exist, and
its CI job checks out with fetch-depth: 0 because actions/checkout fetches no tags at
its default depth. git ls-remote --tags origin still returns nothing here, and the
README, CHANGELOG.md and CITATION.cff now say so rather than implying otherwise.

So the repository is in an honest state, and what remains is the one action that is
yours: creating the signed tag. No agent should do it, and none has. Creating, moving or
deleting a tag and publishing a release are the maintainer's calls.

One thing worth knowing before you cut it, recorded in the gate's own docstring: cut the
signed tag on the same commit that declares the version. Merging a version bump ahead of
its tag puts main into the failing state accurately, because for that window the
repository really does declare a version nothing was tagged for.

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Re-checked 2026-09-06 against origin/main @ d4f533f. Still zero tags (git ls-remote --tags origin is empty) and zero releases. pyproject.toml declares 0.1.0.

This is a maintainer action and stays one. Creating or moving a tag is outside what automation in this campaign may do, and this repository now enforces the honest version of the situation rather than relying on prose: tests/test_release_claims.py (shipped in #68) reads git tag --list and fails if the declared version is neither tagged nor disclosed as untagged in the README status line. So the "declares a version it never tagged" problem is contained — the claim and the reality cannot silently diverge — but the tag itself is still uncut.

Two prerequisites worth checking before cutting it:

1. ci.yml calls its gates merge-blocking; main has no protection at all, and the repo was never registered with the standards program #15's first item. The issue already says to note ci.yml calls its gates merge-blocking; main has no protection at all, and the repo was never registered with the standards program #15 first, and that is still right: main has no ruleset and reports "protected": false, so a tag would be cut from a branch anyone (or any automation holding a token) can force-push. That is the ordering the issue itself proposed and it has not changed.
2. The suite must be green on main first. Until PR The accessibility gate was shallowing this checkout, and five tests about tags paid for it #74 lands, .git/shallow written by the browser accessibility harness makes the release-claims tests fail intermittently on pull requests, and those are precisely the tests that would police the tag.

The signing key exists in this portfolio already (tods-validate and gtfs-scorecard sign with it), so no new key material is needed — only the key holder.

Triaged with AI assistance.

[ChelseaKR]

Still open, and correctly so. Creating a tag is not something automation does in this portfolio.

Two things have moved under it since it was filed, both worth knowing before you cut one:

• The name it would be tagged under is settled. The PyPI name this repo would publish under belongs to yunojuno/django-perimeter #76 is resolved: pyproject.toml declares perimeter-wildfire, which is free on PyPI, rather than perimeter, which is YunoJuno's Django middleware. The blocking condition this issue named upstream of itself is gone.
• ci.yml calls its gates merge-blocking; main has no protection at all, and the repo was never registered with the standards program #15 has narrowed to one action. The protect-main profile is committed at .github/rulesets/main.json and is not applied. It requires required_signatures, so applying it and cutting a signed tag belong to the same sitting.

What is left is yours alone: the signing key, the tag, and the release. The portfolio's release signing key at ~/.ssh/github-release-signing is the one tods-validate and gtfs-scorecard already use, so no new key material is needed. Recorded in the campaign's owner-decisions file.

Prepared with AI assistance; reviewed before submission.