Skip to content

AlgoPhase: drop the non-deterministic "most-recent row" slug fallback#1578

Closed
asdf8675309 wants to merge 1 commit into
danielmiessler:mainfrom
asdf8675309:fix/algophase-deterministic-slug
Closed

AlgoPhase: drop the non-deterministic "most-recent row" slug fallback#1578
asdf8675309 wants to merge 1 commit into
danielmiessler:mainfrom
asdf8675309:fix/algophase-deterministic-slug

Conversation

@asdf8675309

Copy link
Copy Markdown
Contributor

What

AlgoPhase.ts picks which work.json session row to update from --slug, $CLAUDE_SESSION_ID, or --uuid. If none of those matched, it fell back to whichever algorithm-mode row was touched most recently. Run two Algorithm sessions at once (two tabs, or two worktrees) and an unidentified call would quietly bump the wrong session's phase. Saw this happen for real.

Change

One file. resolveSlug() now returns null when nothing identifies the session, so main() errors out ("no algorithm-mode session found — pass --slug or --uuid") instead of guessing. Dropped the pickAlgorithmModeRow() helper. resolveSlug is exported so it's unit-testable.

Why it's safe

That fallback only fired when the caller passed no identifier and $CLAUDE_SESSION_ID wasn't set — exactly the case where there's no right answer. Every normal call (hooks, or an explicit --slug/--uuid) is untouched. Worst case now is a clear error telling you what to pass, and it writes nothing. That beats silently corrupting another session.

Verification

Tested on macOS, Bun 1.3.14.

input old behavior new behavior
--slug S row S row S (unchanged)
$CLAUDE_SESSION_ID matches a row that row that row (unchanged)

End-to-end: 'AlgoPhase.ts build' with no identifier and $CLAUDE_SESSION_ID unset prints the error and leaves work.json byte-identical (md5 unchanged).

Scope

Just AlgoPhase.ts. No API or flag changes — the --slug/--uuid/$CLAUDE_SESSION_ID paths don't move. No new dependency.

## What
AlgoPhase.ts picks which work.json session row to update from --slug,
$CLAUDE_SESSION_ID, or --uuid. If none of those matched, it fell back to
whichever algorithm-mode row was touched most recently. Run two Algorithm
sessions at once (two tabs, or two worktrees) and an unidentified call would
quietly bump the wrong session's phase. Saw this happen for real.

## Change
One file. resolveSlug() now returns null when nothing identifies the session,
so main() errors out ("no algorithm-mode session found — pass --slug or
--uuid") instead of guessing. Dropped the pickAlgorithmModeRow() helper.
resolveSlug is exported so it's unit-testable.

## Why it's safe
That fallback only fired when the caller passed no identifier and
$CLAUDE_SESSION_ID wasn't set — exactly the case where there's no right answer.
Every normal call (hooks, or an explicit --slug/--uuid) is untouched. Worst case
now is a clear error telling you what to pass, and it writes nothing. That beats
silently corrupting another session.

## Verification
Tested on macOS, Bun 1.3.14.

| input | old behavior | new behavior |
|-------|--------------|--------------|
| --slug S | row S | row S (unchanged) |
| $CLAUDE_SESSION_ID matches a row | that row | that row (unchanged) |
| --uuid U matches a row | that row | that row (unchanged) |
| no identifier, 1 algo row alive | bumps that row (maybe wrong) | null -> errors, no write |
| no identifier, 2 algo rows alive | bumps most-recent (wrong ~50%) | null -> errors, no write |

End-to-end: 'AlgoPhase.ts build' with no identifier and $CLAUDE_SESSION_ID
unset prints the error and leaves work.json byte-identical (md5 unchanged).

## Scope
Just AlgoPhase.ts. No API or flag changes — the --slug/--uuid/$CLAUDE_SESSION_ID
paths don't move. No new dependency.

Co-authored-by: Claude <noreply@anthropic.com>
@danielmiessler

Copy link
Copy Markdown
Owner

Your diagnosis is exactly right — and it's exactly why AlgoPhase no longer exists. The tool was retired and deleted from source on 2026-07-14: phase is written only via ISA frontmatter now, so the non-deterministic fallback (and the whole CLI) is gone, it's in the retired-capability registry, and it's absent from the next release's payload. Declining only because the file you're fixing is already deleted — the analysis was correct, and "a clear error beats silently corrupting another session" is the right instinct everywhere. Thank you.

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