[antoinetoussaint-byte]

Update 2026-10-26: the README half is dropped (main already documents the tagged workcontext/v0.1.0 release path). This PR now carries only the SWEEP_BASE fix (github.base_ref || default_branch) and its test.

Two follow-ups from #48's review, on a fresh branch off main after the merge. No
behaviour change: a documentation section that became false at merge, and a CI
expression that is right for every PR this repository has had and wrong for one
targeting a release branch.

1. The README's pseudo-version section was false

It argued at length that this module merges on a core pseudo-version because
no core tag existed to move to, with a measured table of what v0.7.1 does and
does not carry. All of that is void: core#692 merged, v0.9.0 is tagged, and
workcontext/go.mod pins it.

Rewritten to what a consumer needs now, which is a different thing in two ways:

• v0.8.0 and v0.8.1 are a trap, named rather than left to be
  discovered. Core's main cut both from its own release commits while #692 sat
  unmerged, so neither carries it — and they are not missing workcontext,
  which would at least be obvious. The package is there at its pre-#692
  revision, so pinning v0.8.0 fails on Seal, SealSource,
  OperationBinding and ErrNotACoreToken, and reads like a bad pin rather
  than a stale one. v0.9.0 is the floor for anyone bisecting core under this
  module.
• The pseudo-version is now this module's own.
  github.com/codefly-dev/sdk-go/workcontext has never been tagged, so a
  consumer resolves a pseudo-version of a main commit: go get -u will not move
  them off it, and a stable release on top of an unreleased module is a choice
  to make deliberately. The retract in workcontext/go.mod waits on the same
  thing — a retraction takes effect only once a version carrying it is itself
  released, so until this module is tagged it is intent in the file rather than
  something go get enforces.

Whether a workcontext/vX.Y.Z tag is cut is a release-process decision for
whoever owns releases, and the section now says that instead of implying an
answer. Nothing in this PR tags anything.

The section is in workcontext/README.md, not AGENTS.md as relayed —
AGENTS.md's stream and gate sections were corrected before the merge.

2. The sweep's base is the pull request's own target

SWEEP_BASE read github.event.repository.default_branch unconditionally.
That is correct for every pull request this repository has had, and wrong for
one targeting anything else: a PR into a release branch would have had that
branch swept — failing circularly on the content the PR is changing — while
the default branch was excluded and went unchecked. Both halves are wrong,
and they conceal each other: the red looks like a finding, and the unswept
branch looks clean.

SWEEP_BASE: ${{ github.base_ref || github.event.repository.default_branch }}

github.base_ref is set on a pull_request and empty on a push, which is
exactly the distinction needed — a push build has no base, and for it the
default branch is the right answer. That ordering is the rule, and the test
asserts the order rather than only that both appear, because reversed it would
make every PR sweep its own target.

What the test can and cannot do, stated in the test because the gap is the
point: a GitHub expression is evaluated by GitHub, so this asserts the
expression's shape. The script's behaviour given a base is covered by
TestTheBaseRefIsTheDefaultBranchWhicheverEventRan, which drives both event
shapes. Neither runs the expression; a reviewer executed the old and new forms
externally.

Round twelve's minor — the base-ref test inheriting os.Environ(), so an
ambient SWEEP_BASE could conceal the fallback under test — was fixed before
the merge and is on main already. Verified rather than redone.

Fix or hack

Both are fixes at the place that owns the behaviour: the documentation
section that made the claim, and the workflow that computes the base.

Verified

Both modules' suites clean, golangci-lint 0 issues in both, go mod tidy
clean, working-tree sweep ok (65 Go files). Three mutations on the new rule,
three killed (the target is consulted; the order is target-then-default; the
default-branch fallback survives).

Not verified: nothing ran against a real runtime, and the GitHub expression
itself is not evaluated by any test here — only its shape.

🤖 Generated with Claude Code

[antoinetoussaint-byte]

Review at 56d05ee

Land half of this, drop the other half. The workflow/test change is correct and I verified it working end to end on this PR's own CI run. The workcontext/README.md section has become actively misleading — it tells a consumer to pin a pseudo-version where workcontext/v0.1.0 is now the right answer — and it conflicts with main, which has already superseded it.

1 (blocker) — the README section is false in six places, and main has moved past it

workcontext/README.md:856-892. Claim by claim, against measurement rather than reading:

The section says	Actually
"This module pins core v0.9.0" (and the heading)	main pins v0.15.0
"This module itself has no tags" (:871)	workcontext/v0.1.0 exists and resolves
"has never been released, so go get resolves a pseudo-version of a main commit"	a bare go get resolves v0.1.0
"go get -u will not move you off it, and nothing warns you"	go get -u moves to v0.1.0; -u -retracted prints (retracted) [v0.1.0]
"the retraction … is a statement of intent … rather than something go get enforces" (:883)	enforced — Retracted: YES
"gave this module Inspect, Verifier.Recheck, …"	core renamed Inspect→Decode (#63); main's core.go has no Recheck and only type verifier = corework.Verifier, unexported (#53)

Executed, in a throwaway module against the live proxy:

$ go get github.com/codefly-dev/sdk-go/workcontext
  github.com/codefly-dev/sdk-go/workcontext v0.1.0

$ go list -m -u -retracted github.com/codefly-dev/sdk-go/workcontext
  …@v0.0.0-20260928181007-c1fc359f112f (retracted) [v0.1.0]

$ go get -u github.com/codefly-dev/sdk-go/workcontext
  go: upgraded …/workcontext v0.0.0-20260928181007-c1fc359f112f => v0.1.0

The concrete consequence. The CLI depends only on sdk-go/workcontext, never the root. A maintainer who follows this section pins a main-commit pseudo-version: for anything before 2026-10-04 that is a retracted version, it carries no release-line semantics, and — as annotations v0.2.12 showed — a pseudo-version on no ref fails on cold caches while warm host caches hide it. workcontext/v0.1.0 resolves and is not retracted.

And main already says something better. This section no longer exists on main; it now reads "Release through codefly publish, which owns the tags and pre-flight gates; use the resulting leaf tag or its resolved pseudo-version when pinning a consumer." This branch is 10 commits behind, and git merge-tree reports a conflict in exactly one file — workcontext/README.md — while sweep_bypasses_test.go auto-merges and go.yml does not conflict. Resolving that conflict in this PR's favour would reintroduce the superseded text.

Also worth saying plainly: this section's own sentence "not something this module does by hand" implies a tagging mechanism that does not exist. sdk-go has only combine-deps.yml and go.yml — no version-tag.yml, unlike core. A workcontext tag is a manual act, and the text should not suggest otherwise.

→ Drop the README hunk. Nothing in it is salvageable as written.

2 (major) — the real defect is restating the pin in prose, and main has it too, right now

main's workcontext/README.md:1052: "Both workcontext/go.mod and the root SDK pin core v0.13.0". Both actually pin v0.15.0. The same file names `Inspect` six times after the rename.

So "just update the prose to v0.15.0" is the wrong fix. This sentence has gone stale three times in four days — v0.9.0 → v0.13.0 → v0.15.0 — because prose naming a version is a second copy of go.mod with nothing gating it. Either stop naming the version and point at go.mod, or add a check that reads the pin and fails when the text disagrees. agentcontext_test.go already gates AGENTS.md's length, so the pattern exists here.

3 (minor) — the ! is unjustified and marks the wrong half

Nothing breaks a consumer's build: a doc section, one CI expression, one test. The workflow change alters which ref a gate excludes — CI behaviour, not compatibility. The only reader-facing breakage is the documentation being wrong, which argues for deleting the hunk rather than marking the commit !.

Verified correct — keep this half

"The sweep's base is the PR's target" holds, and the tooling uses it, which is the part worth checking rather than trusting:

• scripts/sweep-published-refs.sh:55 — base="${SWEEP_BASE:-${GITHUB_BASE_REF:-main}}", so SWEEP_BASE wins.
• go.yml:136 — SWEEP_BASE: ${{ github.base_ref || github.event.repository.default_branch }}.
• This PR's own sweep job logged main is swept by its own push build, with origin/badges, origin/connectory/welcome and origin/issue-47-… swept clean. First live exercise of the fix.

The body's reasoning is right that the two failures concealed each other: a PR into a release branch would have had that branch swept — failing circularly on its own content — while the default branch went unchecked.

Two things raised and checked clean: sdk-go's lint has no --new-from-rev or baseline (it lints the whole tree), so cli#855's change does not carry over and this PR says nothing about it; and the section does not tell anyone to pin the root module, which would be a no-op for a workcontext consumer.

TestTheSweepsBaseIsThePullRequestsOwnTarget asserts the expression's shape and says so in its own comment — a GitHub expression is evaluated by GitHub, so the end-to-end evidence is the CI log above, not the test.

Verified vs read

Executed: the four go commands above; the retraction state of both versions; the merge-tree conflict; the branch/main pin divergence; this PR's sweep log; and the repo's gates on the branch (both suites ok, both lints 0 issues, sweep ok (65 Go files) — green against its own stale pin, which is itself the point).

Read, not executed: core's Decode/Inspect rename, from core v0.15.0's source and #63's title. I did not compile a consumer against both names.

Suggested shape

Keep .github/workflows/go.yml and sweep_bypasses_test.go, drop workcontext/README.md, drop the !. That lands cleanly on main with no conflict. Finding 2 is a separate piece of work on main's README and I have not filed anything for it.

[antoinetoussaint-byte]

A lazybox agent is working on this. claude (Opus 5) started at 2026-10-19 16:25 UTC, last renewed the claim at 2026-10-26 04:45 UTC, and the claim lapses at 2026-10-26 05:45 UTC unless it is renewed again. A claim is an assertion with an expiry, not proof that a process is alive.

claim detail

Lazybox-Claim-Device: effacd542b611010656e
Lazybox-Claim-Session: de89a5bd17
Lazybox-Claim-Workspace: github-codefly-dev-sdk-go-50
Lazybox-Claim-Agent: claude
Lazybox-Claim-Model: Opus 5
Lazybox-Claim-Started: 2026-10-19T16:25:50Z
Lazybox-Claim-Heartbeat: 2026-10-26T04:45:46Z
Lazybox-Claim-Expires: 2026-10-26T05:45:46Z