Session naming: default launch uses bare name (`code-reasonix`), only `-n` gets a timestamp

[wviana]

Observed

How	Session name	Old session preserved?
reasonix code (first run)	code-reasonix	N/A
Relaunch without flags	Resumes code-reasonix	✅ — but in-place, same file
reasonix code -n / --new	code-reasonix-202503211430	✅
/new in TUI	Same session (e.g. code-reasonix)	❌ — messages overwritten

How we got here

• Before PR feat: Timesteamped session allowing mutiple sessions by project. #12 — no timestamped sessions at all. Every launch used the bare name (code-reasonix). Starting fresh overwrote in place.
• 043dcb7 (Apr 30) — feat: Timestamped session allowing multiple sessions by project introduced timestampSuffix(), findSessionsByPrefix(), resolveSession().
• 9714d11 (same day) — Fix for new session without interaction falling back to default old session style patched findSessionsByPrefix to exclude .events.jsonl sidecars.
• 34464ff (same day, PR feat: Timesteamped session allowing mutiple sessions by project. #12) — fix(session): preserve old sessions on "new"; clean .plan.json sidecars (#12) landed the current design.

The current logic (session.ts:107):

forceNew=true     →  code-reasonix-<timestamp>   (from -n/--new)
forceNew=false    →  code-reasonix               (default launch path)
forceResume=true  →  code-reasonix-<timestamp>   (latest prefixed)

The default branch (!forceNew && !forceResume) still resolves to the bare name with no timestamp — same as before the PR. The timestamp suffix was only wired into the --new and --resume paths.

The asymmetry

Three places create a "new" session, each with different semantics:

Trigger	What happens
reasonix code (first launch)	Plain name, no timestamp — but there's nothing to overwrite, so no harm.
reasonix code -n / --new	Timestamped name — old session preserved.
/new in TUI	loop.clearLog() rewrites .jsonl to [] — old messages lost, same filename.

Additionally, /new at runtime doesn't call resolveSession at all — it just truncates the current session file. So even if the default launch path were fixed to always use timestamps, /new would still overwrite in place.

Questions

1. Should every session name carry a timestamp by default (not just -n/--new)? So reasonix code creates code-reasonix-202503211430, and re-launching without flags picks up the latest code-reasonix-*.

2. Should /new in the TUI also spin off a new timestamped session instead of truncating the current one? This would preserve old conversations for later browsing via /sessions.

3. Is the current /new design (truncate in place) intentional to keep the system prompt hash stable for cache-first? The comment at clearLog says "keeps session + immutable prefix (cache-first invariant)" — but the system prompt hash derives from rootDir, not sessionName, so a timestamped child session would produce the same hash.

Related: resolveSession already exists and works — it just isn't wired into the launch default path or the /new slash handler.

[esengine]

Thanks for the dig — the table makes the asymmetry hard to argue with, and the commit archaeology saved me a re-read of #12.

My read of the three questions:

1. Default launch always timestamped? I'd lean no. The current reasonix code → bare code-reasonix works because re-launching without flags resumes-in-place; that's the muscle-memory case (most users expect the latest conversation to come back on code with no flags). Forcing a new timestamped file every launch would mean the picker grows even when the user just relaunched after a Ctrl-C.

2. /new in TUI should fork. Yes — the ❌ row in your table is the only one that destroys data. /new should mint ${baseName}-${timestamp}, repoint loop.sessionName (so future appends land in the new file), reset loop.log / loop.scratch, and leave the old .jsonl + sidecars untouched. The old conversation stays browseable via /sessions. The cache-first invariant is fine — you're right that prefix hash derives from rootDir, not the session name.

3. Cache-first concern. The clearLog doc-comment is misleading — it says "keeps session + immutable prefix" but only the prefix part is load-bearing. Forking the session name doesn't touch the prefix.

Scope of #2 is bigger than it looks though, because mid-session session-name swap has to thread through:

• App.tsx session prop (drives loadSessionMeta / patchSessionMeta, hooks reload, events.jsonl sidecar path, dashboard subscriptions)
• loop.sessionName (where appends actually go)
• The dashboard's getSessionName() / event subscribers
• useScrollback.reset() semantics — currently nukes cards; we'd want a fork variant that keeps the rendered scrollback OR clears it but keeps it browseable separately

I'll cut a PR for #2 only as a tracking-issue follow-up. Punting the default-launch question.