chore(porch): pir-272 state commits stranded after #305 merged - #309
Merged
Conversation
The review shipped saying a pairing-issued one-time token is spent on the first sweep tick before anyone spawns, and that an unbounded desktop seed is therefore effectively mandatory. That is wrong. The architect verified against a live server that the token is durable and re-exchangeable — nothing is burned. The real cost is smaller and different: each exchange mints a SESSION, so the sweep accumulates one per server every 30s. A leak, not a spent credential, and it wants a different fix — reuse the access token across ticks rather than provisioning another kind of credential. Tracked in #306. Corrected in place with the wrong version named rather than quietly rewritten, because it was merged and someone may have read it. A merged review is what gets grepped in six months. The underlying mistake is worth stating: I propagated a constraint documented in a comment on ThreadBackendConfig.bootstrapToken as though it were a measurement. It was not, and the live check disagreed with it. Refs #272, #306.
This reverts commit 872d4eb.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
--mergedrecord porch wrote for PR #305 landed onbuilder/pir-272after that PR had already merged, so it never reachedmain. This carries it across.Contents:
codev/projects/272-the-sidebar-tree-needs-every-w/status.yaml—merged: true,merged_at, and the matchingupdated_at. One file, nothing else.One thing worth naming
Before merging
origin/mainin, this branch also carried a regression to another builder's state: it would have deletedmerged: trueandmerged_atfromcodev/projects/bugfix-298-.../status.yamland rolled itsupdated_atbackwards from20:02:35to19:55:09.That was not a hand-edit. This worktree held a copy of that file from before bugfix-298 recorded its own merge, and
porch done 272 --merged 305committed whatever was in the tree alongside its own write. Mergingorigin/mainfirst resolved it — the file is now identical to main and absent from this diff, whichgit diff --name-only origin/main..HEADconfirms.Worth knowing generally: a porch state write commits the tree, not just the file it changed, so a stale sibling
status.yamlin a long-lived worktree rides along as a silent revert of somebody else's project state. Related to #233.Refs #233, #272.
🤖 Generated with Claude Code