chore(git): 18 rescued stash branches have never been adjudicated — no issue, no PR, no record of whether their content landed

18 rescued/stash-* branches survive from a May–June stash rescue. None has an issue or a PR, so nothing tracks whether their content ever landed, and nothing will notice if it did not.

Why they cannot simply be deleted

They are 4 months old and main has moved underneath them, so a three-dot diff shows their whole content as "different" whether or not it landed. And per the recorded gotcha, reviving a stale branch here carries a reversal in most cases — one sampled below removes code that is currently on main.

Triage (files each touches that are ABSENT from main — the only possible unlanded content)

branch	touched	absent from main
`stash-2026-05-10-18b82cecd`	2	1
`stash-2026-05-11-17fa01759`	16	6
`stash-2026-05-12-a29826ebf`	19	1
`stash-2026-05-12-f6fd80143`	10	1
`stash-2026-05-24-495ca57a2`	68	2
`stash-2026-05-24-5cb35cd73`	10	0
`stash-2026-05-26-f228c4207`	5	0
`stash-2026-05-27-092dc0da0`	80	2
`stash-2026-05-29-83f45ae45`	24	4
`stash-2026-06-03-44ddffdb4`	18	0
`stash-2026-06-03-44ddffdb4-tracked`	18	0
`stash-2026-06-03-9c4ed9d61`	15	3
`stash-2026-06-04-36d1298b9`	35	1
`stash-2026-06-04-5d317d187`	17	0
`stash-2026-06-05-0d711d576`	88	17
`stash-2026-06-05-3d399c0b9`	2	0
`stash-2026-06-05-426b6737d`	60	33
`stash-2026-06-05-b074f4ef9`	4	0

One worked example, to show the shape

stash-2026-06-05-b074f4ef9 touches 4 files, 0 absent from main, which looks retirable. It is not obviously so:

claude_code_adapter.py        main:470  stash:452   main is ahead
test_claude_code_adapter.py   main:602  stash:652   stash is ahead
bedrock.py                    main:586  stash:671   stash is ahead
test_bedrock_credentials.py   main:235  stash:236   stash is ahead

So it would both reverse work on one file and possibly restore unlanded work on three. Line count is not content, so the real answer needs the diffs read. Multiply by 18.

One already retired, for the method

stash-2026-06-05-1557e2b21 was retired on the authority of #16861's own acceptance criterion, after each of its 23 files was accounted for:

the shared-link migration is superseded by 20260919_095_shared_link_tracking.py, which is on main
services/transcript_export/* is the retired mock surface from wiring: api/transcript_export.py serves mock transcript data — bind to transcriber storage #9958, which "served fabricated data"; tests/api/test_transcript_export_retired.py exists to stop it returning
enhanced_orchestration/workflow_planning.py was renamed to orchestration/, and main's version is a 567-line superset with zero top-level defs unique to the stash
the remaining 17 files exist on main; one is a stray docker-compose-logs/failure-logs.txt

That is the standard the other 18 deserve and have not had.

Acceptance criteria

Every rescued/stash-* branch ends in one of two states: retired with its content accounted for file by file, or converted into an issue describing the work it carries
A retirement records WHY each absent-from-main file is not lost — superseded, renamed, or deliberately retired — not just that the branch is old
Nothing is deleted on a line-count or file-existence heuristic alone; the worked example above shows both give the wrong answer
The adjudication distinguishes "carries no unlanded content" from "was not examined"

Adjudication has started. Two of the original 19 are retired with their content accounted for, and the remaining ones now have a per-branch verdict instead of a count.

Method that works

Three tests, in order. Each answers something the previous one cannot:

Files absent from main — the only possible unlanded content. Everything else is landed or superseded.
Where an absent file went — renamed, superseded, or deliberately retired. Absence alone means nothing.
Top-level symbols present on the stash and not on main — the test that survives refactors. Line counts do not: a stash can be 85 lines larger and carry nothing, or 113 lines smaller and carry something.

Absent-file clusters, all resolved

absent on a stash	where it actually is on main
`enhanced_orchestration/{workflow_runner,workflow_planning,blocked_plan_resumer}.py` (+tests)	renamed to `orchestration/` — all three present; `workflow_planning` is a 567-line superset with zero defs unique to the stash
`services/transcript_export/*_exporter.py`	the retired mock surface from #9958 that "served fabricated data"; `tests/api/test_transcript_export_retired.py` stops it returning
`views/LLMApiKeysView.vue`	moved to `views/secrets/LlmApiKeysView.vue`
`components/settings/MobileDevicePairingPanel.vue`, `composables/mobile-devices/useMobileDevices.ts`	GH#4463 shipped as `components/mobile/PairDeviceDialog.vue` + `composables/usePairingQR.ts`; backend is on main too
`autobot-backend/__init__.py`	deliberately absent — package layout

Per-branch verdict

branch	python symbols only on the stash
`stash-2026-05-11-17fa01759`	`orchestrator.py`:2 `types_test.py`:1
`stash-2026-05-12-a29826ebf`	`schemas_code.py`:5 `http_client.py`:1 `ssot_config.py`:1
`stash-2026-05-12-f6fd80143`	none
`stash-2026-05-24-5cb35cd73`	`probe.py`:2 `enums.py`:3 `test_health_probe.py`:3
`stash-2026-05-26-f228c4207`	`conftest.py`:2 `ssot_config.py`:1
`stash-2026-06-03-44ddffdb4-tracked`	`plugin_install.py`:5 `ai.py`:1 `export.py`:2 `kb.py`:1 `projects.py`:1 `recordings.py`:1 `transcripts.py`:1 `audit.py`:3
`stash-2026-06-03-9c4ed9d61`	`docx_export.py`:1 `pdf_export.py`:1 `ai.py`:1 `export.py`:2 `kb.py`:1 `projects.py`:1 `recordings.py`:1 `transcripts.py`:1
`stash-2026-06-04-5d317d187`	`core_routers.py`:1 `plugin_install.py`:5 `types.py`:1 `audit.py`:3
`stash-2026-06-05-3d399c0b9`	`database_mcp.py`:1 `common.py`:1
`stash-2026-06-05-b074f4ef9`	`claude_code_adapter.py`:1 `test_claude_code_adapter.py`:5

Retired so far

stash-2026-06-05-1557e2b21 — all 23 files accounted for (authorised by feat(chat): add view tracking and login requirement to shared chat links (GH#8996 follow-up) #16861's own criterion)
stash-2026-05-10-18b82cecd — 2 files: one renamed into orchestration/, one where main is larger and no symbol is lost

Still to do, and why each is not a sweep

stash-2026-05-12-f6fd80143 has no unique python symbol, which looks retirable — but it carries TypeScript composables that are +196, +203 and +121 lines against main (useAuditApi, useBatchProcessing, useOperationsApi). The python test does not cover .ts, so it is not cleared. That is the shape of the remaining work: the cheap tests run out before the answer does.

The other branches each carry between 2 and 8 files with python symbols main does not have. Those need reading, one file at a time.

Re-measured today against origin/main @ 31310392d while sweeping the local branch backlog. 17 branches remain, not 18 — and I deliberately did NOT retire any of them, for a reason worth recording here.

Current triage (absent-from-main = the only content that can possibly be unlanded)

branch	touched	absent from main
stash-2026-06-05-426b6737d	60	33
stash-2026-06-05-0d711d576	88	17
stash-2026-05-11-17fa01759	16	6
stash-2026-05-29-83f45ae45	24	4
stash-2026-06-03-9c4ed9d61	15	3
stash-2026-05-24-495ca57a2	68	2
stash-2026-05-27-092dc0da0	80	2
stash-2026-05-12-a29826ebf	19	1
stash-2026-05-12-f6fd80143	10	1
stash-2026-06-04-36d1298b9	35	1
stash-2026-05-24-5cb35cd73	10	0
stash-2026-05-26-f228c4207	5	0
stash-2026-06-03-44ddffdb4	18	0
stash-2026-06-03-44ddffdb4-tracked	18	0
stash-2026-06-04-5d317d187	17	0
stash-2026-06-05-3d399c0b9	2	0
stash-2026-06-05-b074f4ef9	4	0

stash-2026-05-10-18b82cecd from the original table is gone; the rest match, so nothing has drifted.

Why I retired 208 other branches today and none of these

Today's sweep retired 208 local branches — 14 abandoned issue branches, 114 closed-issue branches, 59 PR review copies, 22 misc scratch — each against a landing authority: a merged PR, or an issue closed on AC evidence, plus a check that base lacks no file the branch touches.

These 17 have no such authority, which is the whole point of this issue. So the seven with zero absent files look retirable by the same test and are not, because the test is weaker here than it was there. "Base has every file this branch touches" does not prove the branch's modifications landed — only that it added no new file. For a closed-issue branch the issue's closure covers that gap. For a rescued stash nothing does.

Applying the same rule to both sets would have been the error this issue exists to prevent: treating a test that was sufficient in one context as sufficient in another because it produced a tidy number.

What would actually settle the seven

For each, the question is narrow: do its modifications to existing files appear in base? That is git diff origin/main...<branch> -- <file> read per hunk, not per file — roughly 54 files across the seven, an hour of reading. I have not done it and am not claiming they are safe.

The two heavy ones (426b673 with 33 absent files, 0d711d5 with 17) are a different problem: at that size they are more likely a feature that never landed than a stash, and the recorded gotcha that reviving a stale branch here carries a reversal in most cases applies most strongly to them.

Correction to something I said elsewhere today

I told another session that origin/main was red on two reach floors. It is not — base passes with one file of headroom, and the red appears only on branches that add counted files. Noting it here because the same class of mistake would apply to this triage: a measurement taken on a branch is not a measurement of base.

Went back and did the per-hunk reading I said would settle these. Two are resolved and retired, and the sweep turned up something that should change what this issue decides rather than just how it is counted.

All 17 are pre-SPDX-migration, and that is disqualifying on its own

Measured tip-to-tip (git diff origin/main <branch>), every one of the 17 would revert 6,796 SPDX license headers. The same number for all of them, because they all predate the repo-wide header migration.

So none of these branches can be merged, rebased or checked out as a branch. Whatever is worth keeping can only be mined hunk by hunk. That is worth stating plainly in the issue title's terms: the question is not "do we revive these", it is "is there anything in them worth extracting before they go".

A note on method, since it cost me a wrong reading first: git diff origin/main...<branch> is against the MERGE BASE and shows only what the branch changed, so it reports zero header reversions. Only the tip-to-tip diff shows that main has moved. For "is this branch behind base" the three-dot form is the wrong tool, which is the opposite of the usual advice for reviewing a PR.

Two resolved and retired, with evidence

rescued/stash-2026-06-05-b074f4ef9 — LANDED. 4 files, 549 insertions covering Bedrock credentials and the Claude Code adapter. All of it is in base, and base is ahead: llc/adapters/claude_code_adapter.py is 470 lines on main against the branch's 452; tests/llm_shared/test_bedrock_credentials.py is 235 against 236, and that single extra line is the branch's OLD copyright header. Its only other delta is un-formatting black-formatted code.

rescued/stash-2026-06-05-3d399c0b9 — SUPERSEDED, and this one is the reason the reversal warning in this issue is not theoretical. Applying it to autobot-backend/utils/common.py would:

-from autobot_shared.security.sql_identifier import validate_sql_identifier
+_SQL_IDENTIFIER_RE = re.compile(r"^[A-Za-z_][A-Za-z0-9_]*$")
+def _validate_sql_identifier(name: str, label: str = "identifier") -> str:

It predates the consolidation of validate_sql_identifier into autobot_shared/security/, so reviving it re-forks a shared security helper back into a local copy with its own regex. Base is also ahead on its other file: api/database_mcp.py is 1076 lines on main against 998.

The remaining 15

Unchanged in status — still held, still no landing authority. But the framing is now firmer: the two I read in full were both superseded, one of them in a way that would have reintroduced a forked security validator. That is two of two, which is not proof about the other fifteen but does say which way to bet.

Corrected branch-only file counts, using the proper test (file exists ON the branch and not on base — the earlier numbers counted paths the branch DELETED as content base was missing):

426b6737d 28 · 0d711d576 17 · 17fa01759 6 · 83f45ae45 4 · 9c4ed9d61 3
092dc0da0 2 · f6fd80143 1 · 495ca57a2 1 · 36d1298b9 1
a29826ebf 0 · 5cb35cd73 0 · f228c4207 0 · 44ddffdb4 0
44ddffdb4-tracked 0 · 5d317d187 0 · b074f4ef9 0 (retired) · 3d399c0b9 0 (retired)

The two heavy ones (426b673, 0d711d5) are where any real salvage would be, and they are also where the reversal risk is highest.

All 17 remaining branches adjudicated and retired. Every one was superseded — none carried work that failed to land.

Read each one's actual content against base rather than judging by diff size. Evidence per branch:

branch	what it carried	superseded by
05-11-17fa01759	`enhanced_orchestration/` (6 files)	merged into `orchestration` by `e2431b8635` (#10666/#10690)
05-12-a29826ebf	`http_client.py` at 467 lines	#15641 split it in three; base keeps the 184-line remainder + `http_client_manager` + `http_egress_guard`
05-12-f6fd80143	`views/LLMApiKeysView.vue`	base has `views/secrets/LlmApiKeysView.vue`
05-24-495ca57a2	`llc/services/ceo_chat.py`	retired — base has `scripts/migrate_ceo_chat_to_sessions.py`
05-24-5cb35cd73	llc health probe (668 ins.)	base ahead: `probe.py` 344 vs 257, `test_health_probe.py` 474 vs 337
05-26-f228c4207	npu pipeline dispatcher (582 ins.)	same code, pre-black and pre-SPDX; base `integration_test.py` 253 vs 252
05-27-092dc0da0	`FrontendHealthMonitor.js`	base has `utils/HealthMonitor.js` — the `Enhanced*`/prefix-stripping campaign
05-29-83f45ae45	slash-command presets: API, model, migration, tests	base has `api/chat_presets.py`; #8595's own closure comment names that file. Its migration `20260529_047` would also COLLIDE — base's slot 047 is `desktop_mobile_devices`
06-03-44ddffdb4 (+`-tracked`)	inline zip hardening, 196-line `audit.py`	hardening consolidated into `_arch` (`_is_zip_symlink = _arch.is_zip_symlink`, `_safe_extract = _arch.safe_extract`); `audit.py` is a re-export shim (#12647)
06-03-9c4ed9d61	`MobileDevicePairingPanel.vue`	base has `components/mobile/PairDeviceDialog.vue`
06-04-36d1298b9	`llc/config.py`	base converted it to a package: `llc/config/__init__.py`
06-04-5d317d187	as 44ddffdb4	same
06-05-0d711d576	transcript exporters, activity types	exporters relocated to `transcriber/export/` (docx/pdf/srt/vtt/segments); base has `test_transcript_export_retired.py`; `api_responses.py` → `utils/response_builder.py`; activity-tracking deleted by `0bdbf2d52a`
06-05-3d399c0b9	local `_validate_sql_identifier`	base imports consolidated `autobot_shared.security.sql_identifier` — reviving would re-fork a security validator
06-05-426b6737d	`LLMProvidersView.vue` + 27 visual screenshots	base reorganised into `views/secrets/LlmApiKeysView.vue` + `ProviderFallbackView.vue`; screenshots are test artifacts
06-05-b074f4ef9	Bedrock credentials, adapter (549 ins.)	base ahead: adapter 470 vs 452; its one "extra" test line was the old copyright header

Two things worth keeping from this

These were never mergeable. Tip-to-tip, each would revert 6,796 SPDX license headers and delete 1.1–1.4M lines — the branch tips are whole-tree snapshots from May–June, not small stashes. Only the three-dot diff was ever meaningful content.

The method that kept giving wrong answers. "Base lacks this file" flagged nine branches as carrying unlanded work and all nine were renames, splits or deliberate retirements. plugin_install.py's zip-bomb and symlink hardening looked exactly like lost security work until base showed it consolidated into _arch. A file that moved is indistinguishable from a file that was lost unless you follow the behaviour.

Nothing in these 17 needs salvaging. Closing.

Reopening: this closed on 2026-09-23 with 18 branches in scope, and 10 of them still exist on the remote. Under the standing owner rule — a branch or worktree left behind means the issue is unfinished even if it is closed — this is not done.

Measured just now by this issue's own method (git ls-remote for survival, files absent from origin/main as the only possible unlanded content):

branch	touched	absent from main
`stash-2026-05-11-17fa01759`	16	6
`stash-2026-06-03-9c4ed9d61`	15	3
`stash-2026-05-12-a29826ebf`	19	1
`stash-2026-05-12-f6fd80143`	10	1
`stash-2026-05-24-5cb35cd73`	10	0
`stash-2026-05-26-f228c4207`	5	0
`stash-2026-06-03-44ddffdb4-tracked`	18	0
`stash-2026-06-04-5d317d187`	17	0
`stash-2026-06-05-3d399c0b9`	2	0
`stash-2026-06-05-b074f4ef9`	4	0

Four still carry files that do not exist on main at all — 11 files across them, which is content that demonstrably never landed by any route.

Stating the method's limit, because the six zeros are the ones that will be misread: absent from main catches only new files. A branch whose changes were to files that already exist shows 0 here and may still hold unlanded edits. 0 absent is not evidence of landing — it means this particular instrument found nothing, and #17316's triage table has always had that boundary. Anyone disposing of the six on the strength of a zero would be reading did not look as nothing found.

Not proposing deletion. The issue body's own reasoning still holds and is the reason these are hard: they are four months old, main has moved underneath them, and the recorded gotcha is that reviving a stale branch here carries a reversal in most sampled cases. Adjudication is per-branch work, not a sweep.

What closing this needs: each of the 10 either disposed with per-file evidence that its content is in base, or its unlanded content carried forward on a branch with an issue. Eight were handled between filing and closure; the record should say which eight and by what evidence, because right now the closure does not distinguish handled from not reached.

Inventory context, for whoever picks this up: 22 remote branches currently have no open PR. These 10 are the never-PR'd half; the other 11 each had a PR that closed unmerged, four of them against issues that are still open (#16020, #15495, #17165, #17271).

All ten surviving branches adjudicated. Four carry content that is definitely not in main; six almost certainly carry nothing but stale versions of lines main has moved past.

branch	files ABSENT from main	files with branch-unique lines
`stash-2026-05-11-17fa01759`	6	10
`stash-2026-06-03-9c4ed9d61`	3	12
`stash-2026-05-12-a29826ebf`	1	17
`stash-2026-05-12-f6fd80143`	1	9
`stash-2026-05-24-5cb35cd73`	0	10
`stash-2026-05-26-f228c4207`	0	5
`stash-2026-06-03-44ddffdb4-tracked`	0	18
`stash-2026-06-04-5d317d187`	0	17
`stash-2026-06-05-3d399c0b9`	0	2
`stash-2026-06-05-b074f4ef9`	0	4

The column that matters is the first, and the second is a trap

Every branch has files with branch-unique lines, and that number means almost nothing here. These are four months old. A branch that touched a file in May has the May version of every line main has changed since — so it shows as "unique" while being strictly older. Acting on the second column would revive superseded code, which is the recorded hazard for this exact branch set.

The first column is different: a file present on the branch and absent from main entirely cannot have landed by any route.

What the four actually hold

stash-2026-05-11-17fa01759
  autobot-backend/enhanced_orchestration/blocked_plan_resumer.py
  autobot-backend/enhanced_orchestration/blocked_plan_resumer_test.py
  autobot-backend/enhanced_orchestration/workflow_planning.py      (+3 more)

stash-2026-06-03-9c4ed9d61
  autobot-frontend/src/components/settings/MobileDevicePairingPanel.vue
  autobot-frontend/src/composables/mobile-devices/useMobileDevices.ts
  docs/features/mobile-device-pairing.md

stash-2026-05-12-f6fd80143
  autobot-frontend/src/views/LLMApiKeysView.vue

stash-2026-05-12-a29826ebf
  autobot-backend/__init__.py

Two of these look like real features that never landed — a blocked-plan resumer with its own test, and mobile device pairing with a component, a composable and a doc. Those are not stash debris; they are unfinished work with a shape.

autobot-backend/__init__.py is the opposite and is worth calling out. Absent from main most likely means main deleted it. Restoring that file would resurrect something removed on purpose — the reversal hazard in its plainest form, and a good argument for why "absent from main" still needs a human read rather than an automatic rescue.

Stated limits

This is a file-level test, not a content review. It says a file is missing; it does not say the code in it is wanted, correct, or compatible with four months of drift.
Zero absent does not prove nothing is unlanded. A branch whose changes were all edits to files that still exist shows 0 here and could still hold a wanted change. The six zeros are probably stale, not provably empty — and the difference matters before anyone deletes them.
I did not read any of the code. Nobody should treat this table as a verdict on whether the work should land.

What closing this needs

The four with absent files: each read once, and its content either carried forward on a branch with an issue, or dismissed with a one-line reason recorded here.
The six with none: a content spot-check on one or two to confirm the staleness hypothesis, then disposal as a set with that evidence.
Whatever is disposed, disposed with per-branch evidence in this thread — not a bulk delete.

Not doing any of the above unilaterally. Nine other orphaned branches were disposed today on proof their trees equalled their merge base; these ten are the residue precisely because that proof does not exist for them.

Two more disposed, four kept. And I have to correct the hypothesis I posted earlier — the six "zero absent" branches were not all stale.

The correction first

My previous comment said the six with absent=0 "almost certainly carry nothing but stale versions". I then tested it properly and got the opposite signal: five of the six carried function definitions that a def <name> search could not find anywhere in main — including, alarmingly, _safe_extract, _is_zip_symlink, _validate_zip_metadata in plugin_install.py and _validate_sql_identifier in two files. Zip-slip protection and SQL identifier validation.

I was about to report unlanded security hardening. That would have been wrong. Every one of them exists in main, extracted to shared modules:

archive_safety.py:23   is_zip_symlink        archive_safety.py:58  safe_extract
archive_safety.py:27   validate_zip_metadata archive_safety.py:97  move_into_target
autobot_shared/security/sql_identifier.py:30  validate_sql_identifier  (+ test)

plugin_install.py:125 re-exports them as _is_zip_symlink = _arch.is_zip_symlink. My search was for def _safe_extract and the definition is def safe_extract behind an underscore-stripped alias — the symbol was grepped instead of the chain being followed, which is the same failure this repo keeps recording elsewhere.

The test that survived

Three conditions, all required: no file absent from main; every branch-only function name resolvable in main under its own name, its underscore-stripped name, or an alias assignment; and spot-checks confirming the destination.

DELETED  stash-2026-06-03-44ddffdb4-tracked   0 absent, all symbols resolve
DELETED  stash-2026-06-05-3d399c0b9           0 absent, all symbols resolve

KEPT     stash-2026-05-24-5cb35cd73           5 symbols unresolved
KEPT     stash-2026-05-26-f228c4207           3 symbols unresolved
KEPT     stash-2026-06-04-5d317d187           1 symbol  unresolved
KEPT     stash-2026-06-05-b074f4ef9           2 symbols unresolved

The four kept are kept because the test could not clear them, not because they are known to hold work. b074f4ef9 is the clearest case of that: I verified by hand that its adapter's invoke/cancel/status live in subprocess_base.py:355-423 — main extracted them to a base class — yet the automated check still reports 2 unresolved. A conservative test that keeps a disposable branch costs a line in a listing; one that deletes a needed branch costs the work. Erring the first way on purpose.

State

Orphaned remote branches with no open PR: 9, down from 22 at the start of the sweep.

Remaining: four rescued/stash-* above plus the four carrying files absent from main — 17fa01759 (6 files, a blocked-plan resumer with its test), 9c4ed9d61 (3 files, mobile device pairing), a29826ebf (autobot-backend/__init__.py, which main most likely deleted), f6fd80143 (LLMApiKeysView.vue).

Those eight need a human read. A file absent from main cannot be an alias, and an unresolved symbol is a question rather than an answer.

Third correction, and it resolves the biggest-looking branch. 17fa01759 disposed — its six "absent" files were a directory rename.

I reported it as holding "a blocked-plan resumer with its own test" — 6 files absent from main, the most of any branch here. They are all present:

branch: autobot-backend/enhanced_orchestration/...
main:   autobot-backend/orchestration/...          (renamed)

blocked_plan_resumer.py   main 163L  vs  branch 161L
workflow_planning.py      main 567L  vs  branch 435L
workflow_runner.py        main 696L  vs  branch 382L

main is substantially larger in each — it has moved well past this branch. Reviving it would regress the orchestration package by four months.

This is the third time in this adjudication the instrument was fooled by indirection, each in a different way, and the pattern is worth more than the disposals:

test	fooled by	found by
`git diff` vs merge base	nothing — sound	—
`def <symbol>` in main	an underscore-stripped alias (`_safe_extract = _arch.safe_extract`)	reading the import
file path absent from main	a directory rename (`enhanced_orchestration/` → `orchestration/`)	searching by basename

Each test was correct about the question it asked. None of the questions was "did this work land?"

Remaining: 8 orphaned branches, and the picture is now honest

Two hold work that is genuinely nowhere in main — checked by basename across the whole tree, not by path:

stash-2026-06-03-9c4ed9d61
  autobot-frontend/src/components/settings/MobileDevicePairingPanel.vue   NOT ANYWHERE
  autobot-frontend/src/composables/mobile-devices/useMobileDevices.ts     NOT ANYWHERE
  docs/features/mobile-device-pairing.md                                  NOT ANYWHERE

stash-2026-05-12-f6fd80143
  autobot-frontend/src/views/LLMApiKeysView.vue                           NOT ANYWHERE

Both are frontend features with no trace in the tree. These are the two that deserve a decision rather than a test — mobile device pairing is a component, a composable and a doc, which is a feature someone built and nobody landed. Related: #15145 and #14958 both touch paired-device capability.

One would reverse a deletion: stash-2026-05-12-a29826ebf carries autobot-backend/__init__.py, and the only __init__.py elsewhere in main is an unrelated skills verifier — so main removed it deliberately.

Four remain unresolved by the symbol test (5cb35cd73, f228c4207, 5d317d187, b074f4ef9) — and given the alias and rename findings above, unresolved now means the test could not follow the indirection, not the work is missing.

Orphaned branches: 22 at the start of this sweep, 8 now.

Fourth and fifth corrections — the "two genuine features" are superseded too. Both disposed; no owner decision needed.

I escalated these as work that was "nowhere in the tree" and asked for a rescue-or-discard ruling. Wrong both times, and for two more kinds of indirection:

stash-2026-06-03-9c4ed9d61  (mobile device pairing)
  branch: MobileDevicePairingPanel.vue        main: PairDeviceDialog.vue
                                                    DeviceManagementPanel.vue
  branch: composables/mobile-devices/useMobileDevices.ts
                                              main: composables/useDevices.ts
                                                    composables/usePairingQR.ts
  backend already in main: api/mobile_devices.py, models/mobile_device.py,
    migrations/versions/20260529_047_desktop_mobile_devices.py,
    tests/integration/test_mobile_pairing.py, store_authority entry
  #4463 is CLOSED

stash-2026-05-12-f6fd80143
  branch: views/LLMApiKeysView.vue            main: views/secrets/LlmApiKeysView.vue

The second is the sharpest: same file, different case and a new directory — LLMApiKeysView vs LlmApiKeysView under secrets/. A basename search finds it; an exact-path search does not, and a case-sensitive one does not either.

The doc looked like the one real survivor and is not. docs/features/mobile-device-pairing.md has no equivalent path in main, so it passed every absence test. Reading it settles it: it documents MobileDevicePairingPanel and useMobileDevices — components that were never shipped. Its backend half is accurate (migration and model verified present), but landing it would publish frontend documentation naming files that do not exist. main carries its own: docs/design/2026-06-04-pair-device-dialog.md and autobot-backend/docs/device-token-authentication.md.

Five indirections, one lesson

#	test	fooled by
1	`def <symbol>` in main	an underscore-stripped alias
2	file path absent from main	a directory rename
3	component filename	a renamed component, same feature
4	exact path	a case change plus a new subdirectory
5	doc path absent	a doc that exists but describes what shipped instead

Every one of these tests was correct about the question it asked, and none of the questions was "did this work land?" That question is only answerable by finding where the concept lives, not by matching the artefact's name.

Orphaned branches: 22 at the start of this sweep, 6 now. The remaining six are four with unresolved symbols (5cb35cd73, f228c4207, 5d317d187, b074f4ef9), a29826ebf (would restore an __init__.py main deleted), and release-sync-release (release machinery, not debris).

b074f4ef9 examined to the bottom. Sixth indirection found, and then a genuine residue — two context sections exist nowhere in main.

The branch's _format_fat_context_markdown and its 14 tests looked like a whole unlanded feature. Searching the concept rather than the name found it: main calls it tiered context, not fat context.

branch:  _format_fat_context_markdown   (llc/adapters/claude_code_adapter.py)
main:    chat_workflow/tiered_context_sources.py
         chat_workflow/tiered_context_prompt_test.py

"fat context" appears nowhere in main — a literal search returns zero files. That is indirection #6: a renamed concept, which no filename, symbol or path test can catch.

Section-by-section, which is where it stops being a rename

branch test section    exists in main?
goal_ancestry          YES   tiered_context_sources.py
work_item_section      YES   tiered_context_sources.py
agent_wiki             YES   10 files, incl. llc/adapters/subprocess_support.py
api_config             YES   4 files
rag_chunks             NO    0 files anywhere in main
similar_work           NO    0 files anywhere in main

Four of six landed under the new name. Two did not. rag_chunks and similar_work return zero files across the whole tree, as symbols and as strings.

What I am NOT concluding

I cannot tell from the tree whether those two were dropped deliberately or lost. A four-month-old branch carrying two extra context sections is equally consistent with the refactor narrowed the scope on purpose and two sections fell out during the rename. Those are opposite conclusions and the repository does not distinguish them.

So: branch kept, finding recorded, no rescue and no disposal. Picking between those two readings on plausibility is the error that has produced every correction in this thread.

The question for whoever owns the LLC adapter is one line: were RAG chunks and similar-work retrieval intentionally left out of tiered context? If yes, delete the branch. If no, two sections and their tests are sitting on it.

Sweep total

Orphaned branches 22 -> 6. Six indirections defeated a test in this adjudication — an alias, a directory rename, a renamed component, a case change, a doc describing what shipped instead, and now a renamed concept. Each test was right about its own question; none of the questions was did this work land.

Three more disposed. All four remaining "unresolved symbol" branches resolved by searching the concept rather than the name — the method that has now worked six times.

stash-2026-05-24-5cb35cd73   _get_liveness_monitor, _is_liveness_monitor_running (+3 tests)
  -> main: llc/scheduler/liveness_monitor.py::LivenessMonitor,
           wired at initialization/lifespan.py:1803 _init_liveness_monitor
  The branch held the pre-refactor inline shape in llc/health/probe.py.

stash-2026-05-26-f228c4207   _find_project_root (autobot_shared/ssot_config.py)
  -> main: autobot_shared/paths.project_root(), imported at ssot_config.py:54
           and used at :64, :71
  Extracted to a shared module -- the same pattern as archive_safety.py.

stash-2026-06-04-5d317d187   _get_transcriber_routers
  -> main: core_routers.py:108 imports transcriber_router, registered at :446
  Registration survived; only the private accessor was refactored away.
  Its other "unresolved" symbol was __repr__, which is a detector artefact.

All three were superseded, none held unlanded work.

The count, and what it says about the instruments

Of 22 orphaned branches at the start of this sweep, 18 are disposed and every one was superseded. Not a single disposal turned out to hold work that had not landed.

Six distinct indirections defeated a test along the way:

#	test	fooled by
1	`def <symbol>` in main	an underscore-stripped alias (`_safe_extract = _arch.safe_extract`)
2	file path absent from main	a directory rename (`enhanced_orchestration/` → `orchestration/`)
3	component filename	a renamed component for the same feature
4	exact path	a case change plus a new subdirectory
5	doc path absent	a doc that exists, describing what actually shipped
6	symbol name	a renamed concept (`fat context` → `tiered context`)

Every one of these tests was correct about the question it asked, and none of the questions was "did this work land?" Only searching for where the concept now lives answers that.

The practical lesson for the next sweep: a branch is not proved stale by any single name-matching test. The sequence that worked was: files absent from main → symbols absent from main → the concept absent from main. Only the third is decisive, and it is the only one that cannot be automated cheaply.

What is left: 4

rescued/stash-2026-06-05-b074f4ef9   rag_chunks + similar_work context sections,
                                     absent from the whole tree. NOT a rename --
                                     searched as concept and as string. Needs an
                                     owner ruling: deliberately dropped from tiered
                                     context, or lost during it?
rescued/stash-2026-05-12-a29826ebf   would restore autobot-backend/__init__.py,
                                     which main deleted deliberately
release-sync-release                 release machinery, not debris
Dev_new_gui                          the retiring default branch (#16461)

Only the first needs a decision. The other three are not debris.

Two of the 18 are still on the remote and both are adjudicated: work landed, retire

Read-only; nothing deleted and no branch created. Only two rescued-stash branches survive on origin — the remote carries seven branches in total:

main  release  Dev_new_gui  release-sync-release  automation/test-durations
rescued/stash-2026-05-12-a29826ebf
rescued/stash-2026-06-05-b074f4ef9

So of the 18 this issue tracks, 16 are gone from the remote and these two are the remaining population.

`rescued/stash-2026-05-12-a29826ebf` — landed, retire

Tip a29826ebf3, "WIP on fix-mva138-streaming-cost-chunk", merge-base 4391d8e70 (2026-05-12). Five commits, 19 files, +123/−35. Three separable pieces:

piece	in `main`?
`pyproject.toml` +22: a `[tool.mypy]` block with test exclusions, tagged GH#7105	yes — `main`'s `pyproject.toml` carries `[tool.mypy]`
~16 two-line edits adding `# type: ignore[…] # GH#7105: …` across `autobot_shared/*`	yes — the same baseline work
`openai_compat.py` +16/−10: cost embedded in the usage chunk, standalone cost chunk when `include_usage` is false, tagged #7610	yes — 11 matches for `7610

It also deletes autobot-backend/__init__.py, and main does not have that file either — so the deletion is consistent with main rather than a pending change.

Strong per-file landedness (did main ever hold this blob, not does it now): files=19 identical=0 main-once-held=11 residual=8. The eight residuals are main having moved on across four months, not unlanded work.

`rescued/stash-2026-06-05-b074f4ef9` — landed, retire

Adjudicated in detail on #17115, which owns it: GH#9622's structured-Markdown context work is in main but refactored into subprocess_base.py / subprocess_support.py, and both bedrock files exist in main. files=4 identical=0 main-once-held=2 residual=2.

The same limit applies to both verdicts

I verified subject-level landing — the work of the referenced issues is present in main — and not hunk-by-hunk equivalence. For branches three and four months old that is the right level, because blob equality cannot distinguish never landed from landed and since edited; but it means a hunk the later refactor dropped would not show up here. Both verdicts are "retire on this evidence", not "retire, proven exhaustively".

Why neither was ever reached

Both are invisible to every automated path, which is #16148's subject: branch-cleanup's merged path uses ancestor-based --merged and neither is an ancestor of main; its closed-issue path needs an issue number in the branch name and rescued/stash-… has none; and with no PR, the auto-update bot and the stale-branch reaper never see them.

So the 18 were not adjudicated because nothing could see them, and the two survivors are the proof. Disposal is the owner's call and happens only after the landing is demonstrated — which is what these two comments are for.

Retired 2026-09-28 — and here is where the content went, so this is not a dead ref

Both rescued-stash branches were deleted from origin today with the owner's approval, on the adjudication above and with its caveat stated to them verbatim: subject-level landing verified, hunk-by-hunk not, so retire on this evidence rather than proven exhaustively.

a29826ebf3db692d526ab955e6fc375bf5cd8ca5   rescued/stash-2026-05-12-a29826ebf
b074f4ef951ceb98662189e862fe9c00faacba0e   rescued/stash-2026-06-05-b074f4ef9

origin now carries five long-lived branches — main, release, Dev_new_gui, release-sync-release, automation/test-durations — and no residue.

If you arrived here looking for either branch

It is recoverable, and not by relying on GitHub retaining unreachable objects:

~/rescued-stash-retirement-2026-09-28.bundle   thin git bundle, both tips, verified after the delete
~/rescued-stash-retirement-2026-09-28.md       the record: SHAs, contents, landedness figures, the caveat,
                                               and the exact fetch/push pair to restore either branch

The bundle was built with ^origin/main, so it needs only the two merge bases (4391d8e70, d9776e6f0), both reachable from main. Restore is one git fetch from the bundle plus one git push. Re-verified after the deletion; both tip objects also still resolve in the local clone.

The order this followed, because it is the part worth copying: adjudicate → record recoverably → obtain authority → delete. The bundle is what made the decision cheap in both directions — an irreversible judgement call became a reversible one, which is why it took one word rather than a debate.

chore(git): 18 rescued stash branches have never been adjudicated — no issue, no PR, no record of whether their content landed #17316

Description

Why they cannot simply be deleted

Triage (files each touches that are ABSENT from main — the only possible unlanded content)

One worked example, to show the shape

One already retired, for the method

Acceptance criteria

Activity

mrveiss commented on Sep 23, 2026

Method that works

Absent-file clusters, all resolved

Per-branch verdict

Retired so far

Still to do, and why each is not a sweep

mrveiss commented on Sep 23, 2026

Current triage (absent-from-main = the only content that can possibly be unlanded)

Why I retired 208 other branches today and none of these

What would actually settle the seven

Correction to something I said elsewhere today

mrveiss commented on Sep 23, 2026

All 17 are pre-SPDX-migration, and that is disqualifying on its own

Two resolved and retired, with evidence

The remaining 15

mrveiss commented on Sep 23, 2026

Two things worth keeping from this

mrveiss commented on Sep 25, 2026

mrveiss commented on Sep 25, 2026

The column that matters is the first, and the second is a trap

What the four actually hold

Stated limits

What closing this needs

mrveiss commented on Sep 25, 2026

The correction first

The test that survived

State

mrveiss commented on Sep 25, 2026

Remaining: 8 orphaned branches, and the picture is now honest

mrveiss commented on Sep 25, 2026

Five indirections, one lesson

mrveiss commented on Sep 25, 2026

Section-by-section, which is where it stops being a rename

What I am NOT concluding

Sweep total

mrveiss commented on Sep 25, 2026

The count, and what it says about the instruments

What is left: 4

mrveiss commented on Sep 28, 2026

Two of the 18 are still on the remote and both are adjudicated: work landed, retire

rescued/stash-2026-05-12-a29826ebf — landed, retire

rescued/stash-2026-06-05-b074f4ef9 — landed, retire

The same limit applies to both verdicts

Why neither was ever reached

mrveiss commented on Sep 28, 2026

Retired 2026-09-28 — and here is where the content went, so this is not a dead ref

If you arrived here looking for either branch

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`rescued/stash-2026-05-12-a29826ebf` — landed, retire

`rescued/stash-2026-06-05-b074f4ef9` — landed, retire