public support and security-policy scaffolding is stale #26

New Issue

2026-06-04T16:19:32Z

KofTwentyTwo commented

2026-06-04 16:19:32 +00:00

(Migrated from github.com)

Finding

Several public-facing support and release-readiness files are out of sync with the shipped repository state.

Evidence

docs/license-tool-requirements.md:3 to docs/license-tool-requirements.md:5 still describe the document as pre-implementation and say nothing is implemented yet.
docs/license-tool-design.md:174 to docs/license-tool-design.md:180 still describe repo creation and initial implementation as deferred future steps.
docs/license-tool-requirements.md:54 to docs/license-tool-requirements.md:56 lists issue and PR templates as required scaffolding.
find .github -maxdepth 3 -type f shows workflows and Dependabot only, with no issue templates or PR template.
SECURITY.md:5 to SECURITY.md:8 marks 0.x unsupported while the current released line is still pre-1.0.

Why It Matters

Public users and contributors get contradictory status signals, no structured issue intake, and a security policy that appears to disown the currently released versions.

Suggested Fix

Refresh design and requirements status, add issue and PR templates or remove the requirement, and align SECURITY.md supported versions with the actual release line.

## Finding Several public-facing support and release-readiness files are out of sync with the shipped repository state. ## Evidence - `docs/license-tool-requirements.md:3` to `docs/license-tool-requirements.md:5` still describe the document as pre-implementation and say nothing is implemented yet. - `docs/license-tool-design.md:174` to `docs/license-tool-design.md:180` still describe repo creation and initial implementation as deferred future steps. - `docs/license-tool-requirements.md:54` to `docs/license-tool-requirements.md:56` lists issue and PR templates as required scaffolding. - `find .github -maxdepth 3 -type f` shows workflows and Dependabot only, with no issue templates or PR template. - `SECURITY.md:5` to `SECURITY.md:8` marks `0.x` unsupported while the current released line is still pre-1.0. ## Why It Matters Public users and contributors get contradictory status signals, no structured issue intake, and a security policy that appears to disown the currently released versions. ## Suggested Fix Refresh design and requirements status, add issue and PR templates or remove the requirement, and align `SECURITY.md` supported versions with the actual release line.

KofTwentyTwo commented

2026-06-04 16:30:31 +00:00

(Migrated from github.com)

Status: confirmed — every one of the five evidence points reproduces against the shipped tree at f4a111f (the v0.2.1 commit).

Severity: low (matches the documentation label, no code-behavior impact). The one item with the sharpest real-world edge is the SECURITY.md table: it actively disowns the only released line, which is worse than merely stale — but it is still doc-only.

Verified root cause (this is a docs/scaffolding issue, not a render/detect defect — no INSERT-path or PreserveBoundary involvement):

docs/license-tool-requirements.md:3-5 — "Status: DRAFT" + "Nothing here is implemented yet; repo, issue, and branch creation are deferred". The tool is shipped through v0.2.1, so this is stale.
docs/license-tool-design.md:174-180 — "## Post-approval sequencing (deferred until you approve this design)" lists repo creation, scaffolding, initial implementation, and tagging v0.1.0 as future steps. All already done (tags v0.1.0..v0.2.1 exist).
docs/license-tool-requirements.md:55 — governance-files bullet lists .github/ISSUE_TEMPLATE/{bug_report.md,feature_request.md,config.yml} and .github/pull_request_template.md as required scaffolding. (Note: the issue body cites lines 54-56; the actual list line is 55, with 54 being the section header. Minor.)
.github actuals: find .github -maxdepth 3 -type f returns only dependabot.yml, workflows/release.yml, workflows/ci.yml. No ISSUE_TEMPLATE/, no pull_request_template.md. Confirmed unmet.
SECURITY.md:5-8 — table marks 1.0.x supported / 0.x not supported. There is no 1.0.x release; the version is injected from the git tag via -ldflags -X main.version (.goreleaser.yaml:32, default main.go:13 version = "dev"), and the latest tag is v0.2.1. So the table claims a released line that does not exist and disowns the one that does.

Suggested fix (the v0.2.1 universal-shebang precedent does NOT apply — that was a render/detect dual-boundary + filetype-table fix; this touches no code, so there is no second boundary or filetype table to update, and the 100% coverage gate is unaffected since no .go files change):

Requirements: rewrite the :3-5 status banner to reflect "implemented; shipped through v0.2.1" (or drop the "nothing implemented / deferred" sentence).
Design: convert :174-180 from "deferred future steps" to "completed" (or move to a historical/changelog note).
Issue/PR templates: decide to add .github/ISSUE_TEMPLATE/{bug_report.md,feature_request.md,config.yml} + .github/pull_request_template.md, OR strike them from the :55 requirements list. Adding them is the better path given the public-repo posture, but it is a scope call (see Open questions).
SECURITY.md:5-8: replace the table with the real pre-1.0 reality, e.g. a single 0.2.x — yes row (or >= 0.2.x supported), and drop the phantom 1.0.x row.
Optional hardening: scripts/verify-release.sh only checks SECURITY.md for the release tokens (:107) and README for dry-run (:102) — it does NOT validate the supported-versions table, which is why this stale table sailed through the gate. A grep asserting the table references the current major line would prevent recurrence.

Corrections to the issue:

Line-ref imprecision: the requirements templates claim is on line 55, not the 54-56 range cited (54 is the section header **Governance / community files...**). Cosmetic.
The body undersells the SECURITY.md problem: it is not merely "marks 0.x unsupported while pre-1.0" — it simultaneously claims a 1.0.x line that has never been released. The table is internally fictional, not just conservative. Otherwise the evidence is accurate.

Open questions (maintainer must decide before implementing):

Add the issue/PR templates vs. remove the requirement — which way? If adding, do you want the notion-sql template set mirrored verbatim or a license-tool-specific set?
SECURITY.md policy: support exactly the current minor (0.2.x) or all 0.x? And do you want a forward-looking note for the eventual 1.0?
Should docs/* keep the "DRAFT" framing as a historical record (with an "as of" date) or be promoted to current "as-built" status?

Overlaps: none found among the cited evidence; this is purely the docs/scaffolding surface and does not touch the render/detect code paths other open issues concern.

Automated maintainer review.

**Status**: confirmed — every one of the five evidence points reproduces against the shipped tree at `f4a111f` (the v0.2.1 commit). **Severity**: low (matches the `documentation` label, no code-behavior impact). The one item with the sharpest real-world edge is the `SECURITY.md` table: it actively *disowns* the only released line, which is worse than merely stale — but it is still doc-only. **Verified root cause** (this is a docs/scaffolding issue, not a render/detect defect — no INSERT-path or PreserveBoundary involvement): - `docs/license-tool-requirements.md:3-5` — "Status: DRAFT" + "Nothing here is implemented yet; repo, issue, and branch creation are deferred". The tool is shipped through v0.2.1, so this is stale. - `docs/license-tool-design.md:174-180` — "## Post-approval sequencing (deferred until you approve this design)" lists repo creation, scaffolding, initial implementation, and tagging `v0.1.0` as future steps. All already done (tags `v0.1.0`..`v0.2.1` exist). - `docs/license-tool-requirements.md:55` — governance-files bullet lists `.github/ISSUE_TEMPLATE/{bug_report.md,feature_request.md,config.yml}` and `.github/pull_request_template.md` as required scaffolding. (Note: the issue body cites lines `54-56`; the actual list line is `55`, with `54` being the section header. Minor.) - `.github` actuals: `find .github -maxdepth 3 -type f` returns only `dependabot.yml`, `workflows/release.yml`, `workflows/ci.yml`. No `ISSUE_TEMPLATE/`, no `pull_request_template.md`. Confirmed unmet. - `SECURITY.md:5-8` — table marks `1.0.x` supported / `0.x` not supported. There is no 1.0.x release; the version is injected from the git tag via `-ldflags -X main.version` (`.goreleaser.yaml:32`, default `main.go:13` `version = "dev"`), and the latest tag is `v0.2.1`. So the table claims a released line that does not exist and disowns the one that does. **Suggested fix** (the v0.2.1 universal-shebang precedent does NOT apply — that was a render/detect dual-boundary + filetype-table fix; this touches no code, so there is no second boundary or filetype table to update, and the 100% coverage gate is unaffected since no `.go` files change): - Requirements: rewrite the `:3-5` status banner to reflect "implemented; shipped through v0.2.1" (or drop the "nothing implemented / deferred" sentence). - Design: convert `:174-180` from "deferred future steps" to "completed" (or move to a historical/changelog note). - Issue/PR templates: decide to *add* `.github/ISSUE_TEMPLATE/{bug_report.md,feature_request.md,config.yml}` + `.github/pull_request_template.md`, OR strike them from the `:55` requirements list. Adding them is the better path given the public-repo posture, but it is a scope call (see Open questions). - `SECURITY.md:5-8`: replace the table with the real pre-1.0 reality, e.g. a single `0.2.x — yes` row (or `>= 0.2.x` supported), and drop the phantom `1.0.x` row. - Optional hardening: `scripts/verify-release.sh` only checks SECURITY.md for the release tokens (`:107`) and README for `dry-run` (`:102`) — it does NOT validate the supported-versions table, which is why this stale table sailed through the gate. A grep asserting the table references the current major line would prevent recurrence. **Corrections to the issue**: - Line-ref imprecision: the requirements templates claim is on line `55`, not the `54-56` range cited (54 is the section header `**Governance / community files...**`). Cosmetic. - The body undersells the `SECURITY.md` problem: it is not merely "marks 0.x unsupported while pre-1.0" — it simultaneously claims a `1.0.x` line that has never been released. The table is internally fictional, not just conservative. Otherwise the evidence is accurate. **Open questions** (maintainer must decide before implementing): 1. Add the issue/PR templates vs. remove the requirement — which way? If adding, do you want the notion-sql template set mirrored verbatim or a license-tool-specific set? 2. SECURITY.md policy: support exactly the current minor (`0.2.x`) or all `0.x`? And do you want a forward-looking note for the eventual 1.0? 3. Should `docs/*` keep the "DRAFT" framing as a historical record (with an "as of" date) or be promoted to current "as-built" status? **Overlaps**: none found among the cited evidence; this is purely the docs/scaffolding surface and does not touch the render/detect code paths other open issues concern. _Automated maintainer review._

KofTwentyTwo commented

2026-06-04 20:28:23 +00:00

(Migrated from github.com)

Resolved on develop in commit 742c124e6ec2afa9312075db3112bc2def3c91ff.

Validation:

CI: success, https://github.com/KofTwentyTwo/license-tool/actions/runs/26977377097
CodeQL: success, https://github.com/KofTwentyTwo/license-tool/actions/runs/26977376421
Coverage gate: 100% (2087/2087)

Closing as fixed.

Resolved on `develop` in commit `742c124e6ec2afa9312075db3112bc2def3c91ff`. Validation: - CI: success, https://github.com/KofTwentyTwo/license-tool/actions/runs/26977377097 - CodeQL: success, https://github.com/KofTwentyTwo/license-tool/actions/runs/26977376421 - Coverage gate: 100% (2087/2087) Closing as fixed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/license-tool#26