Skip to content

docs: record the widget v0.4.0 assessment in PLAN_EXECUTED - #20

Open
cdvelop wants to merge 1 commit into
mainfrom
claude/form-v4-record
Open

docs: record the widget v0.4.0 assessment in PLAN_EXECUTED#20
cdvelop wants to merge 1 commit into
mainfrom
claude/form-v4-record

Conversation

@cdvelop

@cdvelop cdvelop commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

You are right that docs/PLAN.md does not exist here — that was deliberate, but its absence is ambiguous and that is a fair criticism. This fixes the ambiguity without inventing work.

Why there is no PLAN.md

The migration already shipped, in #19, as a two-line go.mod bump. main is on widget v0.4.0 and green. There is no pending work to plan.

Writing a migration plan for a go get would have been ceremony — but writing nothing leaves a reader unable to tell "no work was needed" from "nobody looked", especially when the other five repositories in the suite each got a plan. That gap is what this records.

Why it goes in PLAN_EXECUTED.md

This repository already uses docs/PLAN_EXECUTED.md as the record of completed plans. In this suite PLAN.md means an execution document for pending work, so filing a completed assessment there would misuse the convention. The entry is appended alongside the existing i18n plan.

What it records

form never imports widget/style — the package that changed. It uses only the root widget package, and only these symbols, none of which moved in v0.4.0:

NameField (7 uses), PartInput (3), PartLabel / PartError / PartRadioGroup (1 each), State / Locked / Invalid (1 each).

The entire breaking surface of v0.4.0 is inside widget/style. The root package's identity contract was left intact precisely so consumers like this one would not have to move — so this is the boundary working as designed, not luck.

Verified rather than assumed:

go build ./...   → clean, no source edits
go test ./...    → all three packages ok

It also records the invariant that makes the exemption conditional: if form ever imports widget/style, it stops being exempt from that API's migrations and will need its own plan. And it carries the suite-wide state table, so which repositories still owe work lives in the repository rather than in a chat log.

Note on language

The existing entry in PLAN_EXECUTED.md is in Spanish, so this one matches it. The newer documents across widget, ssr, components and layout are in English. Worth unifying at some point — flagging rather than deciding it here.


Generated by Claude Code

The migration itself shipped in #19 as a two-line go.mod bump, with no plan
document, because none was warranted. But every other repository in the suite
did get one, so the absence here is ambiguous: a reader cannot tell "no work
was needed" from "nobody looked".

Records what was checked and why nothing followed from it. form never imports
widget/style, the package that changed; it uses only the root package, and
only NameField, the four Part constants, State, Locked and Invalid — none of
which moved. Verified by building and testing against v0.4.0 with no source
edits.

Filed under PLAN_EXECUTED.md rather than PLAN.md deliberately: the work is
already merged, and in this suite PLAN.md means an execution document for
pending work.

Also records the invariant that makes the exemption conditional — if form
ever imports widget/style it stops being exempt from that API's migrations —
and the state of the other five repositories, so the suite-wide picture lives
somewhere other than a chat log.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DraRNhC3oCA6yupgiYTiKS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants