feat(gatorwalk-factory): lifecycle entries carry issue-lifecycle's versions, counts and attempts (swamp-club #2772) #423
Loading…
Reference in a new issue
No description provided.
Delete branch "cue/2772-gatorwalk-factory-lifecycle"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes swamp-club #2772.
A gatorwalk tracker entry's summary can now say what issue-lifecycle's entries say: which plan version was reviewed and approved, how many findings a review had, and which pull request attempt failed.
What changed
_lib/engine/entry_summary.ts):{{$cycle}}(the attempt, on a stage re-entered per try),{{$version}},{{$version.<product>}}(for an approval, the version in the approval's own products snapshot),{{$input.<name>}}and{{count <field> [key=value]}}. A fixed set, not CEL; every name is checked when the factory definition is saved, against the trigger, the product's schema (the findings contract forkind: findings) and the stage's bindings.on: dispatch(a stage entry's first dispatch, when bindings are resolved, soverification_startedcan name its commit and branch) andon: { transition: <name> }(leaving the stage by it, soattest.complete/merge.completecan postcomplete). An advance can now be two entries; the transition's is written under its own ledger key (-transitionsuffix).build-swamp-extensiondeclares entries that use them; a new test publishes a run of it to the built-in tracker.starterandminimalneeded nothing.swamp data get <key> artifact-<name> --version <version>reads an earlier plan, gatorwalk's answer to issue-lifecycle'sreview --input version).Former "Close" rows
The comparison doc was removed in #2842, so here is how each row closes:
plan_revised"(v2) — feedback round 1"{{$version}}and{{$cycle}}adversarial_review"(plan v2): 1 critical, 0 high"{{$version.plan}},{{count findings severity=critical}}plan_approved"(v2)"{{$version.plan}}on the approve triggercode_conformance_reviewcounts{{count steps status=deviated}}etc.verification_startedcommit and branchon: dispatchwith{{$input.commit}},{{$input.branch}}verification_passed/_failed{{count ...}};failureReasonis a factory-definition fieldpr_linked/pr_merged/pr_failed"(attempt N)"{{$cycle}}of the pull-request stagecompletefrom a transitionon: { transition: complete }Testing
completebeforedone, and a re-run makes no request.🤖 Generated with Claude Code
A tracker entry's summary now reads what issue-lifecycle computes for its entries, from the event as well as the payload: {{$cycle}} (the attempt, on a stage re-entered for each try), {{$version}}, {{$version.<product>}} (for an approval, the version in its products snapshot), {{$input.<name>}} on the new dispatch trigger, and {{count <field> [key=value]}}. Every name is checked when the factory definition is saved. Two new triggers: on dispatch (a stage entry's first dispatch, when bindings are resolved) and on { transition } (leaving the stage by it), so a complete exit posts complete. An advance can now be two entries; the transition's is written under its own ledger key. build-swamp-extension declares entries that use them, and a Lab-fake test drives an issue-lifecycle-shaped run through a revised plan and a second pull request. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>