Skip to content

fix(memory): let the family write to the vault again after a token expires - #55

Merged
arthware-dev merged 1 commit into
mainfrom
fix/memory-token-renewal
Aug 2, 2026
Merged

fix(memory): let the family write to the vault again after a token expires#55
arthware-dev merged 1 commit into
mainfrom
fix/memory-token-renewal

Conversation

@arthware-dev

Copy link
Copy Markdown
Contributor

Ticking off a todo from chat failed with a 401 and no restart helped.

Two causes. The write seam (update_memory) still addressed Forgejo by the LAN address {code_url} renders for phones, so every host-side write went to whatever IP the Mac had at install time; #54 fixed five call sites and missed this one. And the write token is minted once during install and only ever read afterwards, so once Forgejo expired it nothing held a newer one and re-pointing the remote rewrote the dead token every start.

Writes now go to loopback like the rest of the host plane, and a token Forgejo rejects is replaced with a freshly issued one. Only a rejected credential triggers a reissue, so a slow cold start cannot burn a good token.

Follows #54.

…pires

Ticking off a todo from chat failed with a 401 and no restart helped.
Two causes, both invisible from the outside.

The write seam still addressed Forgejo by the LAN address `{code_url}`
renders for phones, so every host-side write went to whatever IP the
Mac had when it was installed. Writes now go to loopback like the rest
of the host plane.

The token was worse: minted once during install and only ever read
afterwards, so when Forgejo expired it nothing held a newer one, and
re-pointing the remote rewrote the dead token every start. A token
Forgejo rejects is now replaced with a freshly issued one. Only a
rejected credential triggers that -- an unreachable Forgejo is left
alone, so a slow cold start cannot burn a good token.
@arthware-dev

Copy link
Copy Markdown
Contributor Author

Verified on the demo rig, which was sitting in exactly this state (401 on every write, Memory vault pull skipped on every start).

The shipped hook repaired it rather than a hand-patch:

✓  Memory: Forgejo rejected the stored token; issued a new one
✓  Memory vault pulled from Forgejo

Then the full loop, including through Stacky's container shim (agent → stack shim → host API), which is the path the bot actually uses:

Added: book the school photo session  (family/education, by homer)
Struck: book the school photo session  (family/education, by marge)
Added: pack gym kit for Bart  (family/education, by bart)

marge — chore(todos): marge ticked off "book the school photo" in education
homer — chore(todos): homer added "book the school photo session" to education

The loopback test asserts where the request lands, not what the code says: the config names TEST-NET-1 (192.0.2.1, unroutable) on the port the test server really listens on, so the request can only arrive if it was rewritten. Reverting the one-line fix makes it go red with URLError: timed out rather than passing quietly.

Unit lane: 2155 passed, 8 skipped. ruff clean.

Known gap, not addressed here: there is still no dirty-working-tree guard before the rebase/reset paths added in #54. Host CLI writes and the curator share one working copy with no lock, so an uncommitted vault edit can be lost to a reset --hard. Worth its own change.

@arthware-dev
arthware-dev merged commit 7227242 into main Aug 2, 2026
1 check passed
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.

1 participant