Some credentials cannot be configured, only obtained: getting one means
a conversation — open this page, paste that code, pick an account. The
new seam owns that conversation and the one-attempt-per-key lifecycle,
and never the protocol, so a second authorization protocol arrives as
another flow rather than as another seam.
A flow is registered under the CredentialKey it writes, which is also
how the seam knows which plugin answers for the format inside that
record. The flow owns the write: run() resolving means the record is
already committed through ctx.credentials, and the seam confirms it.
That keeps a library persisting through its own store adapter the
single writer instead of being copied back out and written twice.
The interaction travels with the request rather than a registry,
because whoever starts an authorization is the one who can talk to the
human about it. A request already withdrawn never claims the key and
never starts the flow — relying on each flow to check its signal before
the first await would let one that does not hang holding the key.
The seam answered one question — what is behind this environment-variable
name — and that shape cannot hold what an authorization grant is: a
multi-field, rotating value keyed by a provider id rather than by a POSIX
identifier. The Models page already works around the gap by inventing a
synthetic environment name (`MINIMAX_CN_API_KEY`) for a route the user added
by hand, because the store's key must look like one.
`CredentialKey` is `<scope>/<id>`, where the scope is the owning plugin's
registered name. The owner is in the key because a `grant` payload is written
in its owner's format: two plugins serving the same provider name would
otherwise read each other's payload, and a record left by an uninstalled
plugin could not be told from a live one. The `/` also keeps the grammar
disjoint from `CredentialRef`, so the key spaces cannot collide.
`CredentialRecord` is `api-key` (key and/or provider environment values) or
`grant` (an opaque, owner-owned payload). The asymmetry is deliberate: an api
key is the harness's own data, a grant is a package it carries for someone
else. `modifyRecord` is the only write path because a correct write depends
on the current value — a token refresh is read-decide-replace under one
cross-process lock, without which two processes rotating one refresh token
lose whichever wrote first.
`.credentials.yaml` becomes a versioned two-section document. The pre-release
flat layout is refused by name, with the entry count and the one edit needed,
rather than read as an empty store — which would surface as an authentication
failure on the first request instead of at load. A grant payload is admitted
in both directions, so a value the document could not read back exactly as
written is refused rather than stored lossily.
Address the latest review pass on PR #2798:
- client-build-environment.client.spec.ts: add release-publish.yml to
dshBuildWorkflows so the 'workflow env must not set DSH_CLIENT_*' gate covers
the new dsh publish path (it runs build:official and writes a dsh client
build record). vendor-publish runs only build:lib:host, so it is not added.
- 2026-08-10-npm-release-sequences note (en/zh/i18n): the Release-publish group
is carried by the publish job (job-level concurrency), not the whole
workflow; corrected the wording.
Address the fresh review pass on PR #2798:
- ci-workflow.spec.ts: restore the subscription-type assertions the rewrite had
dropped (issue-lifecycle pull_request types omit ready_for_review and include
review_requested; pull_request_review types == ['submitted']) alongside the
new step-level gate checks, so the 'tests pin the subscribed events' gate
holds.
- 2026-08-10-npm-release-sequences note (en/zh/i18n): the three-sequence table's
Workflow column now lists the pack and publish workflows for dsh/vendor, and
line 114 no longer claims release.yml publishes (the dsh pack job packs the
vendored family for verification; release-publish.yml repacks and publishes).
Follow-up for the pack-job copy drift is filed as #2816.
Address ds-review-bot findings on PR #2798:
- release-publish.yml: use pnpm run build:official (not build) so the dsh
pack step's verifyBuildArtifacts (families.ts:327, readClientBuildRecord with
officialClientBuildEnvironment) finds the official client-build record; build
would fail Pack release tarballs on a clean runner.
- issue-lifecycle.yml: move the previous job-level if to step level on
Create project token and Handle repository event, so approved/commented
reviews pass (job reported success, no gray segment) without minting a
write-capable App token or touching the board — preserving the original
least-privilege property.
- ci-workflow.spec.ts: lock the step-level gate on the two lifecycle steps, and
add a release-workflow invariant test (release.yml/vendor are pack-only;
release-publish.yml/vendor-publish.yml are workflow_dispatch-only with the
npm-publish environment and Release-publish group) to prevent #2797 recurrence.
- Update 2026-08-10-event-directed-pr-review-status and 2026-08-10-npm-release-
sequences notes (en/zh/i18n) to the new split and step-level behavior.
Verification: ci-workflow.spec.ts 14/14, typecheck clean, all five workflows
YAML-parse, verify-translation-pairing consistent, note-format 582.
Remove the three skipped (gray) checks from the PR check panel without changing
functional semantics:
- issue-lifecycle: remove the job-level 'if' that skipped the lifecycle job on
non-changes-requested pull_request_review events, so it now runs and reports
success (the lifecycle handler already no-ops for approved/commented reviews).
The changes-requested board transition is unchanged.
- release.yml / release-vendor.yml: drop the publish job (and its
workflow_dispatch 'publish' input + RELEASE_PUBLISH pass-through) so it no
longer appears as a skipped Publish-to-npm check on PRs; the files keep the
pack job that validates tarballs on PR/push.
- new release-publish.yml / release-vendor-publish.yml: manual workflow_dispatch
only, repack on the current tree then publish, so publication behaves exactly
as the old publish job (explicit dispatch, uses the packed bytes) but never
shows as a PR check.
Update the 2026-08-10 review-status note (en/zh/i18n) and the issue-lifecycle
spec assertion to match the unconditional lifecycle job.
Verification: ci-workflow.spec.ts 19/19, all five workflows YAML-parse, typecheck
clean, verify-translation-pairing consistent, note-format 582.
The exact-event-set assertion called Object.keys on a Record<string, unknown>'s
on field without narrowing, failing typecheck (TS2769). Guard with isRecord
before asserting the full event sets.
Address the 7 remaining review threads on PR #2768:
- spec: assert the exact full event sets for both workflows (ci-master =
[push, workflow_dispatch], ci.yml = [pull_request]) instead of only the
negated checks, so losing/adding a wrong event fails.
- 2026-07-21 note line 29: 'The ci-master and Sandbox workflows keep their
cross-platform references on master pushes' (en+zh) — ci.yml is PR-only.
- failover-runbook line 19 (en+zh): the push-reachable classification now names
ci-master.yml for the drills/wine cache and ci.yml for the PR jobs, dropping
the stale pull-request-gated phrasing.
i18n hashes re-recorded for both notes; spec 13/13, pairs consistent,
note-format 575.
- The pnpm-caching note placed node-compat in ci-master.yml, but it stays a PR
job in ci.yml; only the two runner benchmarks moved. Correct en/zh line 15 and
re-record the pair.
- The pnpm/action-setup destination test only iterated ci.yml; extend it to also
cover ci-master.yml so its five pnpm setups stay regress-tested.
Per review on PR #2768:
- Restore a concurrency block in ci.yml (cancel-in-progress: true) so a fresh
PR push cancels the superseded run; GitHub has no default PR auto-cancel,
so removing it would stack a second full 9-job run on every push.
Update the ci-workflow.spec assertion accordingly.
- Fix comment misplacements from the split boundary: ci.yml's all-checks-passed
now carries its own branch-protection comment (the drill comment that was
orphaned above it is gone), and ci-master.yml no longer ends with an orphaned
all-checks-passed comment.
- Restore the DeepSeek e2e workflow describe-block in ci-workflow.spec.ts that
the rewrite had silently deleted (e2e.yml is unchanged).
- serial-windows comment no longer claims non-blocking-for-PR/absent-from-needs
since ci-master never listens to pull_request.
- DSH_TELEMETRY_DISABLED safe-use comment restored in ci-master.yml env; split
rationale (mi gray segments in PR check) documented in .github/AGENTS.md.
Verification: ci-workflow.spec.ts 13/13, both workflows YAML-parse with correct
concurrency, git diff --check clean.
Split the single ci.yml into two workflows so the PR check panel stops listing
master-only obs jobs that skip (gray) and block the aggregate green-check:
- ci.yml is now pull_request-only, holding only the 9 PR jobs (node-24,
node-24-coverage, node-24-consumers, node-compat, python-sdk, python-runtime,
windows, windows-native, all-checks-passed). It drops the workflow-level
concurrency block since master carve-outs no longer apply.
- ci-master.yml (new) carries the six master/dispatch jobs (wine-apt-cache,
serial-linux-selfhosted, serial-macos, serial-windows, and both runner
benchmarks) with the push-exempt cancel-in-progress block and suite input.
It does not listen to pull_request, so its jobs never appear in PR checks.
ci.yml keeps the wine apt cache seed/restore (repo-scoped by key), so moving the
producer to ci-master.yml does not break the PR windows job's restore.
Update ci-workflow.spec.ts to assert the two-workflow split: ci-master owns the
drills/benchmarks and the push-exemption concurrency, ci.yml is PR-only without
concurrency. Update the serial-reference, portable-required, failover-runbook,
and pnpm-caching notes (en/zh + i18n) and .github/AGENTS.md to reflect ci-master.
Verification: scripts/ci-workflow.spec.ts 12/12, both workflows YAML-parse,
verify-translation-pairing consistent, verify-agent-note-format passes.
pku-xht