askcc develop repeatedly dies before first commit, leaving uncommitted work stranded in worktree

[ellen-goc]

Summary

Across at least 3 separate repos (weyucou/nemawashi-backend#3, weyucou/ibuki-backend#13, weyucou/mther-infra#42), askcc develop sessions have died before making any git commit — sometimes after writing substantial working code+tests, sometimes with a clean worktree. The issue stays labeled action:develop, remains assigned, and no PR is ever opened, so it silently looks "in progress" to org-scan tooling when nothing is actually happening.

Evidence

• weyucou/nemawashi-backend#3: 4+ separate feature/3-* branches all sitting at the exact same commit SHA as main (zero commits), but the associated .claude/worktrees/* directories contain uncommitted working code + passing tests from multiple independent attempts. The most complete attempt (jaunty-inventing-pony worktree) has a full webhook feature implementation with 11/11 tests passing that was simply never committed.
• weyucou/ibuki-backend#13: two worktrees (humming-greeting-gem, reactive-knitting-sonnet) both stalled with real uncommitted infra work (Dockerfile, CloudFormation template, dependency bumps) but no commits.
• weyucou/mther-infra#42: worktree found completely clean (no uncommitted changes either) — this attempt appears to have died even earlier, before writing any code.
• Stale ellen:processing labels have had to be auto-recovered on nemawashi-backend#3 multiple times (2026-07-02, twice) with no active process found, suggesting this crash pattern predates a single incident and recurs.

Impact

• Real engineering work is silently lost/stranded unless a human (or another agent) happens to inspect the worktree directory before it's cleaned up.
• Issues appear stuck "in development" indefinitely with no visible error, misleading project-board scans into thinking a job is in-flight when it has actually died.

Ask

• Investigate what's causing askcc develop to exit before its first commit (timeout? unhandled API error? OOM?) — logs from the detached launcher (nohup/setsid wrapper) may have more detail if available.
• Consider having askcc commit early/incrementally (e.g. after each file write, or at least once tests pass) rather than only at the very end of a session, so partial progress survives a crash.
• Consider surfacing a clearer failure signal (e.g. a PR comment or issue comment noting "session terminated before commit") instead of leaving the issue silently labeled action:develop with no trace.

[ellen-goc]

Additional evidence for this pattern: weyucou/mther-ui#103 (6-scenario Q&A guardrail smoke test, complexity:medium) has had its ellen:processing label auto-recovered 3 times (2026-07-06, 07-08, 07-09) with no commit and no PR ever opened, despite all its stated dependencies (mther-backend#83/#84/#87) being closed and the issue being otherwise fully DoD-ready. Same silent-death signature as the cases already listed. Also newly confirmed: weyucou/ibuki-backend#13 does have a real partial commit from a died session (47d686b, 2026-07-07, covers 1 of 3 AC tasks) sitting in an orphaned worktree with no PR — salvaging it now rather than re-running from scratch, but flagging since it's more evidence of sessions dying silently mid-task rather than always at zero-commit.

[ellen-goc]

New evidence, same pattern (2026-07-13):

• weyucou/mther-infra#42 — 3rd stall. Worktree giggly-questing-thunder (feature/42-smoke-problem-definition) at same SHA as main, zero commits, clean tree, no PR. Stalled 2026-07-03, 2026-07-07, and (per ellen:processing recovery timestamps) is idle again as of this scan — no salvageable work either time.
• weyucou/mther-ui#103 — 4th stall, including one after the scope was already narrowed down (2026-07-12 comment split S1-S3/S4-S6 specifically to fit session budget). Latest attempt: ellen:processing applied 2026-07-12T21:38:52Z, auto-recovered 2026-07-13T00:00:18Z (~2.4h), zero commits.
• weyucou/mther-backend#97 — also stalled once (ellen:processing recovered 2026-07-13T00:00:21Z), but this time left a partial uncommitted diff in the worktree (bishop/agents/models.py, comment + help_text edit only, not a full implementation). Relaunched today against the same worktree/branch — noting for the "sometimes writes partial code" bucket in the summary.

Not filing a new issue — this is additional data for the existing one. mther-ui#103 is notable because it stalled again even after a deliberate scope-reduction pass, which suggests the failure isn't purely "task too big for session budget."