changeset `share-link-enabled-at-redemption.md` says the refusal "will burst the log once" — the warn is per-hit and unlatched, so it continues with traffic

[huangyiirene]

Split from #14637 (item 2) by the triage seat so it is not held behind that card's ruling. #14637 keeps the substantive half — the route probe's existence oracle — which needs a human decision; this half is a one-sentence correction with no code impact and can land today.

The defect

.changeset/share-link-enabled-at-redemption.md, final sentence of the retroactive-deploy paragraph, at origin/main 2aa8456:

The refusal logs one warn line per refused hit and is not latched, so a retroactive deploy with many live links on switched-off objects will burst the log once.

The first half of that sentence is correct and the second half contradicts it. Per-hit and unlatched is precisely the property that means the volume does not occur once — it continues for as long as traffic reaches those links.

Measured

packages/plugins/plugin-sharing/src/share-link-service.ts, the if (!policy.enabled) arm: this.logger?.warn?.(...) is called on every refused redemption, with no latch, no dedupe and no sampling. Nothing in the arm records that it has fired before.

The code's own comment above it (same file, immediately preceding) states the design deliberately: the readable reason "is written to the server-side log through the GUARANTEED warn member — the caller was answered, so this is not a degradation and not an error". Per-hit is intended behaviour. Only the changeset's summary of it is wrong.

Why it is worth a card rather than a shrug

Release notes are compiled from changesets, so this sentence is an input to a published document, and it is the sentence an operator planning a retroactive deploy would budget against. "Burst once" and "one line per hit until you act" imply different log-retention decisions.

Suggested wording (from #14637, adopt or improve)

…so a retroactive deploy with many live links on switched-off objects will burst the log at deploy and keep logging one line per hit until the block is enabled or the links are revoked.

Scope

⛔ Changeset prose only. No code change — the per-hit behaviour is correct and ruled; do not "fix" it by latching the warn.

⛔ Do not touch content/docs/releases/** here. The changeset is the sanctioned input channel; release notes are compiled centrally at release time.

Re-check: git show origin/main:.changeset/share-link-enabled-at-redemption.md | sed -n '60,68p'

Refs: #14637 (parent finding, item 2) · #14033 · PR #14580

Generated by Claude Code

[os-sales]

Claim: domain:services execution seat

• Session session_01AUF1NoViznQK32gqpK8wS8 (os-sales) · Branch claude/issue-14668-share-link-changeset-burst-wording · Worktree objectstack-issue-14668 from origin/main · Round R16
• File surface — .changeset/share-link-enabled-at-redemption.md, and nothing else unless the measurement below says otherwise.
• Serial constraints — none. plugin-sharing has three fences open on this seat (sharing-service.ts + backfill by PR fix(sharing): stamp organization_id on every sys_record_share write, backfill the stranded rows, admit the object to the tenancy ledger (#14484) #14726; rule-hooks.ts / sharing-plugin.ts / bu-tree-recompute.ts by PR fix(plugin-sharing): let system writes materialize sharing rules — drop the isSystem skips in bindRuleHooks (#13533) #14528; share-link-service.ts by the in-flight finding: getPolicy()'s disabled-branch redactFields read has no reader once publicSharing.enabled is held at redemption (#14033) #14581), and this card touches none of them: a changeset file is not source.
• Container & model — opus. No path-derived tier mandate.
• Clause ② — no; re-derive from the diff before opening the PR.
• Ruling of record — none. The [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033 ruling governs the behaviour the changeset describes; this card is about whether the description is true.

The task is a correction, so establish the truth first

The changeset says the refusal "will burst the log once". The card says the warn is per-hit and unlatched, so it continues with traffic. ⛔ Do not edit the sentence until you have read the emitting site and can say which it is — the point of this card is that a changeset told an operator something false about log volume, and replacing one unverified claim with another is the same defect.

Premise-first stops — any one firing means commit, push, report on the card, stop:

1. The warn is actually latched. If the site does have a once-per-process (or per-link, or per-object) latch, the changeset is right and the card is wrong. Report the code and stop.
2. The sentence is already gone or already corrected on current origin/main.
3. The changeset has been consumed by a release and no longer exists — then there is nothing to correct here and the right target is the release notes, which ⛔ this lane does not edit in a code PR.

What "done" means

• The sentence describes the measured behaviour of the emitting site: whether it fires once or per hit, and per what scope.
• ⛔ Do not rewrite the rest of the changeset. It carries a BREAKING banner and a minor level under the launch-window convention — leave the level, the banner and the surrounding prose exactly as they are. One sentence is the diff.
• ⛔ Never edit content/docs/releases/** — release notes are compiled centrally at release time from this changeset, which is precisely why the changeset's own wording is worth correcting.
• Gates derived, not recalled (dispatch-gates.mjs --commands, exit codes captured before any pipe, each non-zero classified NOT MEASURED vs finding by its own verdict).
• Worktree-first; ⛔ never git stash; commit and push after every explicable step.

If the emitting site turns out to deserve a latch — i.e. the changeset described what the code should do — ⛔ that is a stop and report, not a code change: adding a latch is a behaviour change on a published log sink and needs its own card and its own review shape.

PR

Draft, body Fixes #14668. Report what you measured at the emitting site, with the file and line, and quote both the old and new sentence.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 14668,
  "status": "done",
  "branch": "claude/issue-14668-share-link-changeset-burst-wording",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/14764",
  "premise_still_valid": true,
  "summary": "The card's premise HELD, measured before one word was edited. packages/plugins/plugin-sharing/src/share-link-service.ts:697-708, the `if (!policy.enabled)` arm of `resolveToken()` (the [#14033] gate): an unconditional `this.logger?.warn?.(...)` followed by `return null`. No latch, no Set/WeakSet/Map, no memo, no dedupe, no sampling anywhere on the path. The only mutable class state is `usageStampRefusalReported` (line 423), which latches a DIFFERENT site -- `reportUsageStampRefusal()` (line 842), the #12981 usage-stamp degradation. Firing scope is the HIT: `resolveToken()` is called once per HTTP redemption (share-link-routes.ts:233 and :317) with no cache and no rate limit in front of it. So the changeset's 'will burst the log once' was false and its own first half ('per refused hit and is not latched') was right. One sentence replaced; frontmatter, `minor` level, BREAKING banner, ADR-0087 marker and every surrounding paragraph byte-identical; no source file touched. No premise stop fired (the warn is NOT latched, the sentence was still present and uncorrected on origin/main 7a17f3bf1, the changeset file still exists, and no latch was added -- adding one is a behaviour change on a published log sink and belongs to its own card).",
  "tests": "Gates DERIVED at the final commit cbc0402b3, not recalled: `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands` (no paths; script takes the change set from the merge base itself; stderr confirms 'derived from the tree of objectstack-ai/objectstack at commit cbc0402b3' and '--repo checked against this checkout's origin remote -- it holds'). It named 9 families. All 9 ran green (exit 0), plus 2 run deliberately -- 11/11 zero-exit, 0 non-zero, nothing NOT MEASURED. Each exit code captured into a variable BEFORE any pipe (`eval cmd > log 2>&1; ec=$?`). Verdict lines quoted from the gates themselves: check-adr-0087-registration 'this PR adds no declared-breaking changeset (1 non-breaking changeset(s) seen)'; check-changeset-no-major 'This diff introduces no `major` bump'; check-empty-changeset 'No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added)' -- so Check Changeset and the empty-changeset gate both see the file and both stay green, confirmed rather than assumed; check-keyed-text-bounds '148 keyed text-family columns judged, 148 bounded'; check-half-states, release-rehearsal-clone --self-test, check:changeset-gate-self-tests, check:objectui-changeset, check:pm-half-states all green. TWO ADDED, not padding: (1) `node scripts/check-changeset-fixed.mjs` -- the one family the derivation itself flags as an artifact roster sitting in a directory one of my paths is in, where its silence 'is not evidence in EITHER direction'; ran it: exit 0, '.changeset/config.json \"fixed\" group is in sync with 69 public workspace packages', and reading the script shows it reads only .changeset/config.json plus the workspace package list, so the silence was in fact correct -- no finding. (2) `pnpm check:nul-bytes` -- owed by any edit: exit 0, 'scanned 8052 text file(s) ... no raw ASCII control bytes'; a direct grep -naP over the edited file for the control-byte class is clean too (exit 1, no matches). NO ABLATION IS OWED and this is stated rather than silently skipped: the diff is prose in a changeset -- there is no behaviour to mutate and no test whose failure could be demonstrated; the sentence's CLAIM was verified against the source instead, which is the check that applies. origin/main re-fetched at the end and unmoved at 7a17f3bf1, so the gate union above ran on this branch's final tree (cbc0402b3).",
  "mcp_calls": "2 -- issue_read(get) and issue_read(get_comments) on #14668. The REST channel was probed in-container (repo-scoped GET -> 200) and carried the PR creation, the body read-back and this comment.",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code