baselining swallows the PR-open failure — branches pile up nightly, stamps freeze, run reports ok

[missingbulb]

The defect

deliver() in packs/basics/tasks/baselining/worker.mjs destructured only json from the PR-open POST and never read status:

({ json: pr } = await gh(token, `/repos/${repo}/pulls`, { method: 'POST', ... }));

When that POST fails, the error body lands in pr. pr.node_id is undefined so the auto-merge arm is skipped silently, the CI dispatch has no PR to attach to, and the run still logs preprocessing basics/baselining: ok.

Why it compounds

openMaintenancePull reuses by open PR, not by branch. A cycle that pushes its branch but fails to open the PR therefore finds nothing to reuse next cycle and mints a fresh branch — nightly — while the stamp never advances and nothing surfaces the failure.

Observed fleet state (2026-07-29/30)

Eleven of twelve consumers were frozen on canon ref 7e89c0cf (2026-07-28), each carrying claudinite/maintenance-2026-07-29-* and -07-30-* branches with no PR behind either — several carried two branches for a single day. 27 orphan maintenance branches in total. GoogleCalendarEventCreator, the pilot and the one repo with the Actions PR permission enabled, opened and merged its maintenance PRs normally throughout.

The usual cause is repo-level and invisible from inside the Action: Settings → Actions → General → "Allow GitHub Actions to create and approve pull requests" is off, so the POST 403s.

Fix

PR #584 — pullCreateError(status, json) as a pure predicate, null only on a 201 carrying a PR number; deliver() throws on it and the message names the repo setting. See-it-fail coverage for the 403, a 201 with no PR number, and the no-message fallback.

This stops the silence. It does not enable the setting — that stays an owner action on each consumer, and until it is done #584 converts a silent stall into a loud nightly failure.

Related gaps this surfaced

• Pack manifest as the single source: routing guidance, skills, scoped rules #555 shipped no migration record. Making the pack manifest a closed vocabulary with a required ruleRoutingGuidance blocks every consumer whose local pack still declares bare rules — and since normalizeManifest rebuilds rules from the scoped lists, such a pack's checks silently stop running. Eleven local packs across ten repos were migrated by hand this session.
• No stamp-staleness alarm (Notes v2 retention window silently orphans out-of-scope members — add a stamp-staleness alarm + census/scope reconciliation #331) — nothing noticed twelve repos frozen for two days.
• Seven consumers have no pull_request CI at all, and TLDR's is path-filtered away from .claudinite/**, so their maintenance PRs are never gated by the world sweep.

[missingbulb]

conversation-extract — rule added: "Tightening a contract that member-owned files must satisfy has NO carrier — baseline migrations move paths, not schemas — so it lands as a fleet-wide silent break" (.claudinite/local/packs/claudinite/RULES.md, PR #605). Capture 2026-07-30T2124Z, session 5c9cf57d-05ff-5680-86ef-d1cf194b79fb.

The session was asked to open every member repo, baseline it by hand and apply all migrations. Piloting the converge on TLDR surfaced two new blocking findings that were not on its main before — both from the tightened pack-manifest vocabulary. Chasing that down took the session through pack-schema.mjs to the fact it names in one line: worldRules/workRules are flattened into rules with a scope stamp, so a bare rules field means the pack's checks silently stop running. It then had to rewrite eleven local pack manifests across ten members by hand, and afterwards EdFringeNow's CI went red because those packs' own tests still asserted pack.rules.

What makes it a rule rather than an incident is the carrier gap. A converge may not edit a member's own .claudinite/local/packs/, and migrations/ cannot help either — a baseline migration is declared as a path relocation (aliases: [{ canonical, legacy }]), with no way to express a field rename inside pack.mjs. So the change had no delivery mechanism available to it, which is why #555 shipped without a record: there was none to ship. The rule asks what carries a contract change across the fleet before tightening it, and refuses the degradation mode where a stale declaration yields fewer checks running instead of a failure.

---

Generated by Claude Code

[missingbulb]

conversation-extract — rule added: "This repo's fleet machinery reports success from reaching the end of the code path, not from the artifact — check the response, and alarm on the stamp" (.claudinite/local/packs/claudinite/RULES.md, PR #605). Capture 2026-07-30T2124Z, session 5c9cf57d-05ff-5680-86ef-d1cf194b79fb.

The session opened on the owner asking whether the per-repo baselining problem was solved, closing with "I feel the situation is bad." That instinct was the only detector in the system. Surveying the fleet showed nine members frozen at the same 07-28 canon ref with maintenance branches accumulating nightly, and the diagnosis landed at the line this issue records: the PR-open POST's status was never read, so a 403 put the error body in pr, pr.node_id came back undefined, the auto-merge arm was skipped without comment, and the run still logged ok. Every nightly run had been green throughout the freeze.

Two habits come out of it, and the rule states both. Read the status of any API write whose result you then branch on — destructuring only the body turns a refusal into a plausible-looking object that flows onward. And judge fleet health by the members' stamps, never by scheduler run conclusions: the stamp is the one artifact that moves only when baselining actually delivered, which reframes the stamp-staleness alarm (#331) from a nice-to-have into the missing guard. PR #584 fixed the swallow itself; the rule is about not writing the next one.

---

Generated by Claude Code