| name | finishing-cldk-work |
| description | Use when implementation on a CLDK branch is complete and the work needs verification, merge, release, documentation updates, and issue closeout — before claiming any CLDK work is done. |
Finishing CLDK work
The ladder's exit. Every other rung — designing-cldk-changes,
maintaining-cldk, codeanalyzer-backend, cldk-sdk-frontend — terminates
here. Nothing is "done" until it has passed through this gate: gates green,
a real ship decision, release mechanics if warranted, and closeout.
Entry Preconditions
Implementation is complete on a branch. Most arrivals come from
maintaining-cldk, carrying a propagation verdict in hand (the
required output of its propagation sweep — a list of follow-on repos, or
none with its reasoning). Arrivals from codeanalyzer-backend or
cldk-sdk-frontend carry no verdict of their own; treat their Terminal
State handoff as "implementation complete, gates not yet re-run here."
Either way, do not start from a bare "it's done" claim with no artifact
behind it.
Verification Gates
Which commands to run depend on the repo type — analyzer, SDK, or docs —
see the full matrix in references/release-gates.md.
No success claim, no tag, no release, no 'done' without running the gate
commands NOW and reading their output. 'Passed earlier' is not evidence.
A same-day CI run, a teammate's "LGTM," or your own memory of an earlier
pass are all the same failure shape: assurance detached from a command you
just watched execute. Re-run the gate on the exact commit you're about to
act on.
Ship Decision
Passing gates only tells you the branch is mergeable — it does not tell you
whether to release. Decide explicitly:
- Forces a release: a behavior change reaches users (a bug fix, a new
field, a new accessor), or a downstream pin needs to move (an SDK's
codeanalyzer-<lang>==X needs the fix that just landed).
- Merge-only, no release: docs-only changes, internal refactors with no
observable behavior change, test-only changes. Merge and stop — cutting a
release train for these is manufacturing release noise, not shipping
value. The one exception: if docs are themselves published from a tagged
release (a docs-site build keyed to a version), a "docs-only" change can
still need one — check before assuming not.
Release Mechanics
Once a release is warranted, mechanics differ by repo type — full detail in
references/packaging-and-release.md:
- Analyzer (
codeanalyzer-<lang>) — a tag-triggered pipeline: PyPI thin
wheel, GitHub Release binaries, and a Homebrew formula push, all cut from
one vX.Y.Z tag in lockstep.
- SDK (
python-sdk, typescript-sdk, …) — bump the analyzer version
pin to the just-released version, then the SDK's own release.
Never tag off a stale local build; the tag is what the pipeline trusts.
Closeout
Docs updates, issue/epic bookkeeping, and following the propagation verdict
through — full etiquette in references/docs-and-closeout.md. In brief:
update the surfaces that describe what changed, close the child issue(s)
this work resolves (sub-issue progress rolls up on its own), and for every
repo the propagation verdict listed, file the follow-on issue before
stopping — a verdict that lists a repo and gets no issue is a dropped
thread, not a closed one.
Terminal State
finishing-cldk-work is the ladder's exit. If the propagation verdict listed
follow-on repos, each becomes a new maintaining-cldk entry.
Checkpoint before re-entering. Report what shipped and what the propagation
verdict found, then AskUserQuestion — file the follow-on issues and start the
first one now, file them and stop, or stop here entirely (see
using-cldk-devtools → Transition Checkpoint). Re-entering the ladder is a
transition like any other; do not roll straight from a release into new work.
