docs(changeset): the pending callerParamKeys note no longer lists the schedule trigger as leaving it absent (#19900)

[objectstack-fleet]

Part of #19900
Clause-②: no

The pending release note this corrects

This PR edits one sentence of .changeset/19846-automation-caller-param-keys.md, the pending note for AutomationContext.callerParamKeys (PR #19899). The note's frontmatter covers @objectstack/spec, @objectstack/runtime and @objectstack/service-automation. Nothing else in the note changes, frontmatter included (1 line changed: +1 / −1).

Before:

Record-change, schedule, time-relative and webhook triggers, and code calling execute directly, leave it absent.

After:

Record-change, time-relative and webhook triggers, and code calling execute directly, leave it absent; the schedule trigger, whose run has no caller, states an empty list (#19900).

What made it false: PR #19982, landed as ae7a35a63b. Since that commit, ScheduleTrigger sets callerParamKeys: [] on every run context it builds, so the schedule trigger no longer leaves the key absent. PR #19982's own changeset (.changeset/19900-schedule-caller-param-keys.md) reaches only the @objectstack/trigger-schedule and @objectstack/spec CHANGELOGs. The @objectstack/runtime and @objectstack/service-automation CHANGELOGs would publish this sentence unchanged.

The gate is expected to stay red

node scripts/check-empty-changeset.mjs --base origin/main exits 1 on this head. This is a DELIBERATE CORRECTION of a foreign pending note, and the gate stays red on it by design until a person confirms the rewritten sentence (the seat's ruled path: ruling D on #17712, and the landing rule added in #19970). Its output begins:

Diffing HEAD from ae7a35a63 (merge base with origin/main).
✓ No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added).
This PR changes a changeset it did not add:

   .changeset/19846-automation-caller-param-keys.md
     present on the merge base and CHANGED by this PR -- this is somebody else's release note

The DELIBERATE CORRECTION remedy it prints is: "do NOT restore it -- say so on the PR and get it confirmed". This section is that statement.

skip-changeset: not applied

Two readings, and they agree. (1) This diff changes release-note text that changeset version will compile into three published CHANGELOGs, so it is not a diff that publishes nothing. (2) The standing rule for a PR that edits an existing .changeset/*.md is never to apply skip-changeset: the red gate is correct, and the confirmation goes through the PR text.

Gates (head 465a0f9342)

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 19 commands from the change set (merge base ae7a35a63). All 19 ran with their exit codes recorded. 18 exited 0, and check-empty-changeset.mjs --base origin/main exited 1, as expected above. pnpm check:changeset-gate-self-tests exited 0. The --ran reconciliation reads: 19 derived, 19 run, 0 NOT-MEASURED.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 465a0f9342

_{Rendered by an isolated at-tier reviewer and adopted by the domain:services seat (session_01Evb5jFDZGKQE9KG4jbMfMF). Under the DELIBERATE CORRECTION landing rule (#19970), this record is the confirmation of the foreign-note edit: it names the note and judges the rewritten sentence.}

① Derived judgments

• Edited note: .changeset/19846-automation-caller-param-keys.md, the pending note of PR feat(spec,runtime,service-automation): the flow doors state callerParamKeys, and the headless screen verdict reads it #19899 / AutomationContext: an explicit caller-provenance signal for flow params, replacing the headless-screen inference of PR #15787 (#15705 ruling ②) #19846.
• Before: 「Record-change, schedule, time-relative and webhook triggers, and code calling execute directly, leave it absent.」
• After: 「Record-change, time-relative and webhook triggers, and code calling execute directly, leave it absent; the schedule trigger, whose run has no caller, states an empty list (A scheduled flow run skips a screen whose required field is named schedule, jobId or flowName: the schedule trigger's own params are read as the caller's answers #19900).」
• Clause 1 — TRUE on origin/main. None of these producers sets callerParamKeys:
  • record-change-trigger.ts (params: isolatedRecord);
  • time-relative-trigger.ts (params: record);
  • api-trigger.ts (params: { ...payload });
  • the one non-test direct execute caller (examples/app-showcase/src/security/seed-approval-demo.ts). resolveRunContext only spreads the incoming context.
• Clause 2 — TRUE. schedule-trigger.ts sets callerParamKeys: [] in the one context it builds; this landed in ae7a35a63b (PR fix(trigger-schedule): a scheduled run's platform seeds never answer a screen field (#19900) #19982). It is the only non-test event: 'schedule' producer.
• The unchanged tail still holds: subflow-node.ts and map-node.ts delete the key from the child context.
• Scope of the diff: exactly one line (+1/−1). The frontmatter, the note's own Clause-②: yes and every other paragraph are byte-identical to the merge base. No other sentence of the note is falsified by fix(trigger-schedule): a scheduled run's platform seeds never answer a screen field (#19900) #19982.

② Semver level

Unchanged and still right: @objectstack/spec minor, @objectstack/runtime minor, @objectstack/service-automation patch. The correction is descriptive text and publishes no new act.

@objectstack/trigger-schedule does not belong on this note. Its behaviour change carries its own note, .changeset/19900-schedule-caller-param-keys.md. The (#19900) cross-reference lets readers of the runtime and service-automation CHANGELOGs, which that note does not reach, find the superseding change.

③ Boundary flags

• Part of #19900, no closing keyword: correct. A scheduled flow run skips a screen whose required field is named schedule, jobId or flowName: the schedule trigger's own params are read as the caller's answers #19900 closed through fix(trigger-schedule): a scheduled run's platform seeds never answer a screen field (#19900) #19982. The whole body was scanned, and no closing keyword precedes any card number.
• No skip-changeset: correct. The diff changes text compiled into three published CHANGELOGs, and route 0 of the Require a changeset step refuses the label for an edit to an existing .changeset/*.md.
• Clause-②: no: correct. It is text only; no code, type, schema or reader moves.
• Not governed. .changeset/ is not a governed surface.
• Nothing blocks the merge. Check Changeset is red by design, and every other check must be green before enqueue.

Implemented-by: claude/issue-19900-19846-note-correction
Reviewed-by: session_01Evb5jFDZGKQE9KG4jbMfMF

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Check Changeset is red by design on this PR, and it will be enqueued with that one row red · domain:services seat · session_01Evb5jFDZGKQE9KG4jbMfMF · 2026-09-24T15:14Z

• Which gate, and why it is red. Check Changeset (pr-automation.yml → changeset-check, scripts/check-empty-changeset.mjs) fails on head 465a0f9342 because this PR CHANGES a pending release note it did not add, .changeset/19846-automation-caller-param-keys.md, and adds none of its own. The job's own error line says: 「if its only .changeset rows are CHANGED, not added, this PR corrects somebody else's pending release note -- do NOT apply 'skip-changeset'; write the confirmation on the PR, naming the note and what changed under it, and leave this check red ([finding] the skip-changeset label suppresses the DELIBERATE-CORRECTION refusal whose own text says 「no label and no diff shape makes that safe」 — declared contract against enforced behaviour #18375)」.
• What changed under the note. PR fix(trigger-schedule): a scheduled run's platform seeds never answer a screen field (#19900) #19982 (ae7a35a63b) made the schedule trigger state callerParamKeys: [], so the note's 「schedule … leave it absent」 became false. The one-sentence correction is judged TRUE clause by clause in the at-tier record above (PASS, same head). Under pm-dispatch: three landings the seat decides on its own record (ruling 1A, 2A, 3A) #19970 that record is the confirmation.
• The three conditions for enqueueing with a red row, all met:
  1. The gate's source states that it stays red by design for this class: 「this gate stays red either way, and staying red is what puts the decision in front of a person」.
  2. The job runs on pull_request only, never on merge_group.
  3. This comment names the gate and the cause.
• Every other check on the head must be green before the flip to ready and auto-merge.

---

Generated by Claude Code