@oakoss/oakum 0.3.0 → 0.3.1

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # Changelog
 
+## 0.3.1 (2026-09-16)
+
+### Changed
+
+The workflow `init` and `migrate` print identifies the version pull request by head repository and author, not by branch name alone. `github.head_ref` carries no owner, so in a public repository any fork could name its head branch `oakum/version-packages` and skip `oakum check --strict`; a collaborator could do the same from a branch in the repository itself, and so could anyone pushing to the bot's branch, since that raises a `synchronize` whose pull-request author is still the bot. All four terms hold for any repository, so nothing has to be filled in: they test the head repository and the `type` of the pull request's author and of the event's sender, never a named account. The skip reaches the genuine version pull request only once its author is a bot whose push retriggers CI — under `secrets.GITHUB_TOKEN` that pull request raises no workflow run at all, so there is nothing to skip, and the comment above the step now says so rather than warning about a hole that is not one.
+
+`oakum ci version-pr` says who the token opened the pull request as, on stderr — stdout stays the one URL a caller captures. A run under a personal access token opens it as a person, which the scaffolded skip does not excuse, so every check runs on the version pull request and the only other symptom is a longer bill. The identity is reported where it was measured rather than left to be inferred from a workflow that did or did not fire. It is reported, not read as a verdict: a person settles the question, because that term alone defeats the skip, while a bot does not, since the skip also tests the sender of the event the push raises and no run can see that from here. A response that omits the author, or omits its type, says so instead of defaulting into a verdict.
+
+The workflow `init` and `migrate` print surfaces a `pr-status` run that could not post its report. That step carries `continue-on-error`, so a GitHub outage does not fail a contributor's check; the same setting also let a report that never posted pass for one that did, and left a green check over a log nobody opens. A step now follows it that, when the step failed, emits a warning into the run summary and names the check above as what still decides. It runs whether or not the check itself passed, since a failed check is exactly when the report matters. A post that fell back to the job summary, the designed path for a fork with no token that can comment, is not a failure and does not warn. oakum's own workflow gains the same step.
+
+### Fixed
+
+`oakum check` prints its refusals as blocks, the deciding line first. Each refusal's summary comes first with its detail indented beneath it, and every refusal that did not decide the exit code follows as `also …` in the same shape, so a reader meets the verdict before what is subordinate to it, and evidence sits under the line it supports; two looks that fail identically say it once, keeping what each found. Before, each look printed its detail as it ran and its summary at the end, so the management guidance could sit five lines from its summary with three unrelated lines between, and `also` lines printed before the line they were also-to. `tag-drift` prints the same block for the same state, and with a stale install pin beside real drift it now exits 1 for the drift and names the pin as `also`, as `check` does.
+
+Among refusals of one class, the order `check` announces decides which one carries the exit code, and the install pin is its own look after the tags. With git wholly unusable, the first line a reader meets says git could not run, not `install pin is 9.9.9`. Before, the pin was verified inside the tag look and before git was touched, so a stale pin decided for a repository whose git did not work. A base ref git cannot resolve is quoted on the scope line by its first line only; the coverage look still carries the whole failure.
+
+No command loses its output to a panic when the reader has gone away. `println!` and `eprintln!` abort on a refused write, so `oakum version | head -1` exited 101 — neither ok, unverified, nor error under ADR-0034 — with its files already written and no account of them, and every other command shared the hazard. 0.3.0 said both channels went through a write that reports failure rather than panicking; that was true of `check` alone.
+
+Every command now prints through writers that do not abort, and they differ by what the line is. A report — a `check:` scope line, a `pending:` plan, a migration step — survives a refusal in silence, because a reader who went away chose not to read. A result is the command's return value: the path `add` wrote, the URL `release` or `ci version-pr` opened, the plan `status` prints and the JSON `status --json` and `plan-intent` produce, the body `generate --dry-run` composes, the listings `reachable-tags` and `detect-release-tools` are, the summary `version` or `upgrade` gives of what it changed, the `created` records and the workflow `init` and `migrate` hand over, and the plan `ci pr-status` falls back to stdout when it has neither a token nor a job summary. A result nobody received is a run that did not answer. It exits 2, `unverified` under ADR-0034: the work landed and the answer did not, the same shape as a `migrate` that applied every file and could not verify them. Stderr says what already happened, so a caller that captured an empty stdout under `set -o pipefail` is told rather than left to notice. A descriptor the caller closed outright (`>&-`) is not a reader who went away: the standard library reports that write as delivered, and the run exits 0.
+
+`init` and `migrate` finish every write before reporting a refused record, so a reader that went away does not leave `.changeset` half-written, and the verdict names each line that never arrived, even when a plan-comparison finding outranks it for the exit code; a write that fails after such a refusal, a gate look that fails beside it, or a comparison that could not run is named in the same verdict. An interactive prompt propagates the refusal because a question that cannot be shown cannot be answered. A `release` stopped by such a refusal keeps that class through its partial-failure report rather than reading as an error, and that report lists a tag whose GitHub release exists as `released` and not as remaining. A test fails the build naming any command module that reaches for the macros again.
+
+`oakum ci pr-status` identifies the version pull request by the same four facts the scaffolded workflow tests — head branch, head repository, and the type of both the author and the sender — where it read the branch name alone. A fork or a collaborator naming a branch `oakum/version-packages` was treated as the version pull request, which suppressed the coverage comment on their own change. The cost of the other mistake is a redundant comment on the real version pull request, so an event that cannot be read counts as not the version pull request.
+
+`oakum ci pr-status` reads `.changeset/_config.toml` once per run. It read it twice, once to choose the channel and once more inside the state builder to compose the plan, so a config edited between the two reads could choose a channel with one config and build the plan with another. `status`, `ci pr-status`, and `version` share one plan pipeline; `version` carried its own copy of it.
+
+A release assembled from a bump file that declares more than one section renders each under its own heading. A note's first line was the only one read for a section name, so a file carrying `### Added` and `### Changed` was filed under the first and printed the second inside that block; 0.3.0's own changelog repeats `### Changed` and `### Fixed` for that reason. A known heading now starts a section wherever it appears, at up to three columns of indentation — the rule CommonMark applies and the one oakum's fence reader already used — while a fourth column is code, an unknown heading such as `### Notes` stays body text, and a heading inside a fenced block stays content. A heading with nothing but whitespace under it renders no section rather than a heading over two spaces. A template iterating `changes` or `notes` sees the same correction: a bump file's second section is its own entry, sharing that file's commit, pull request and author, rather than a stray heading buried inside the first entry's body. The rows a template rendered before were the bug, not a contract it can keep. MD024 stays disabled repo-wide, because specs and decision records repeat headings by design; the rendered changelog asserts the rule itself instead.
+
+A `version` run that fails partway names every file it left changed, as a list. Rollback appended `; restoring X also failed (...)` to the cause once per file, which buried the last entry of a chain, and the one run where the tree is left half-written was the one that said least about it. The failure now prints the cause, a count, and one path per line. Two states that were silent are now named as files left changed: a staging file the run created and could not remove, and a file the run created and could not remove after the write itself failed. A directory the sweep could not read is named too, on its own line and under its own heading, because it is no evidence of a changed file — the fault that strands a file is the kind that also blocks the listing, so silence would hide a leak exactly when there is one, while counting it as damage sends a reader hunting for a half-written tree that may be intact. A staging file is attributed to this run by a delimited process id rather than a substring match, so a concurrent run's file is not named as this failure's; the wording holds either way. An empty list is documented for what the code checks — every restore reported success and every swept directory could be read — and no longer claims a byte-identical tree, which rollback does not verify because it writes the planned original back without re-reading it.
+
+`version` writes a file it planned to create with an empty body, where the unchanged-text skip dropped the write and reported success over a file that never appeared. No caller produces one today.
+
+`version` no longer loses its summary to a panic when the reader has gone away. `println!` aborts on a refused write, so `oakum version | head -1` exited 101 with the manifests, changelogs and bump files already written and no account of any of it — on the one command that performs the irreversible part of a release. The summary now goes through the same write that `check` was given in 0.3.0, which reports a refusal rather than panicking. Other commands still print directly, which is tracked separately.
+
 ## 0.3.0 (2026-09-12)
 
 ### Added
@@ -166,4 +200,4 @@ Release workflow checks out the homebrew tap in a subdirectory so the composite
 
 Self-host release CI uploads cargo-dist artifacts into the GitHub Release oakum already created, instead of calling create again.
 
-Generated by oakum 0.2.0.
+Generated by oakum 0.3.0.

package/npm-shrinkwrap.json

@@ -19,7 +19,7 @@
       "hasInstallScript": true,
       "license": "MIT",
       "name": "@oakoss/oakum",
-      "version": "0.3.0"
+      "version": "0.3.1"
     },
     "node_modules/detect-libc": {
       "engines": {
@@ -48,5 +48,5 @@
     }
   },
   "requires": true,
-  "version": "0.3.0"
+  "version": "0.3.1"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "artifactDownloadUrls": [
-    "https://github.com/oakoss/oakum/releases/download/v0.3.0"
+    "https://github.com/oakoss/oakum/releases/download/v0.3.1"
   ],
   "author": "Jace Babin",
   "bin": {
@@ -105,7 +105,7 @@
       "zipExt": ".tar.xz"
     }
   },
-  "version": "0.3.0",
+  "version": "0.3.1",
   "volta": {
     "node": "18.14.1",
     "npm": "9.5.0"