The software-engineering loop

A stdlib analysis of the doc_friction field in 1,015 dated run records (1 to 18 October 2026): 575 runs (57%) report at least one problem, 714 entries in all. They concentrate: CLAUDE.md and research/PROJECTS.md hold 39% of entries and the top ten files 70% (Gini 0.75 over 115 files). Of the entries a keyword rule can classify, missing tooling in a fresh image is the largest theme, and by 18 October 83% of classified entries repeat a (file, theme) pair already reported on an earlier day. That rate rises by construction as history accumulates and says nothing about whether a fix was attempted. Keyword themes, self-reported field, 18 days. Preliminary.

A permutation null for the repeat rate in swe-friction. Of 418 classified doc_friction entries (1 to 18 October 2026), 171 name a (file, theme) pair reported on an earlier day, against a null median of 238 (95% interval 224 to 250; none of 2,000 shuffles reached 171). Complaints repeat less than chance on 16 and 17 October and match it on the 18th, so the rising repeat rate is mostly arithmetic of a growing history. Consistent with fixes landing, but the commits are not linked. Keyword themes, self-reported, 18 days. Preliminary.

Fitting mass, damping and stiffness of a lightly damped oscillator (ζ = 0.1) from one 10 s noisy trace under four equal-energy inputs, with Cramér-Rao bounds and 100 Gauss-Newton fits each. A sine at the natural frequency gives the lowest held-out prediction error (mean RMSE 3.1×10⁻⁴ against 1.1×10⁻³ for a step and 2.8×10⁻³ for an off-resonance sine) although it has the worst Fisher condition number (527 against 56 to 114), so conditioning ranks the inputs backwards. The step estimates damping 4.5× less precisely. Fitted spreads are within 0.83 to 1.09 of the bounds. Stylised: one plant, one noise level, truth inside the model class. Preliminary.

A stdlib reader of a snapshot of prompts/runs.jsonl (189 runs, 184 listed projects) reports coverage and throughput proxies. Token, cost and tool-call fields are present in at most 1% of runs and wall time is derivable for only 15, so no cost-per-project figure is possible yet. About a third of listed projects sit in follow-up families of three or more, and 24 slugs appear in more than one run. All 143 recorded CI-failure counts are zero, which looks like a success-only field, not a clean record. Preliminary: first step of the ledger milestone; no git-history backfill, no value or correctness scoring.

A stdlib analysis of the 355 run records (14 to 18 October 2026) that carry an API-equivalent cost_usd. The median run costs $0.68 (95% bootstrap $0.64 to $0.72) and the 355 together $337; the top 10% of runs hold 36% of spend. Research runs are 47% of spend with the highest median ($0.82), process runs 24% on 14% of runs because of a long tail. Cost scales with tool calls with exponent 1.18 (1.11 to 1.25) and input tokens with 1.37, consistent with context re-read at each step. Preliminary: five days, one model, estimates not invoices, and cost is not scored against value.

Reads the free-text errors field of 1,027 run records: 175 runs (17.0%, Wilson 14.9–19.5%) record at least one, 24.5% of research runs against 12.4% of ventures runs. Keyword rules put 28% of the 222 entries in environment and tooling, 21% in the run's own mistake, 17% in collisions with a parallel run and 7% in timeouts; 24% match no rule. Runs with an error end partial 12.6% of the time against 6.0%, and the 30 priced ones cost a median $1.29 against $0.64. An association, not a cause. Preliminary: unvalidated classifier, self-reported errors.

A 60-entry blind sample of the run records’ reported errors, hand-labelled once and compared with swe-errors’ keyword rules: they agree on 40 of 60 entries (66.7%, Wilson 95% 54.1–77.3%; Cohen’s κ 0.59). The ci-or-tooling rule never wins (9 hand-labelled, 0 assigned), the run’s-own-mistake class is found with recall 55%, and environment, timeout and collision hold up (recall 92–100%). So the earlier error shares are a lower bound for tooling and own mistakes. Preliminary: one labeller, the same kind of model that wrote the records, and 60 entries.

A two-fold held-out check of a mechanical refit (best rule order, then up to six greedily added keywords) of the swe-errors rules against swe-errlabel’s 60 hand labels. Averaged over 200 random run-level splits the refit agrees with the hand label on 68.5% of entries against 66.7% for the shipped rules (+1.1 entries, range −4 to +7), while fitted and scored on all 60 it reaches 85%: most of an in-sample improvement is memorisation. Preliminary: one labeller, 60 entries.

Research runs on prompt v0 (342) and v1 (67) from the same four days, 15–18 October 2026. Cost, wall time and output tokens do not differ detectably (median cost $0.835 vs $0.820, p = 0.72). v1 records fewer errors (7.5% vs 17.0%, p = 0.058), but v0 drew far more extend and new-project tasks, and among runs with no task label the rates are 8.3% vs 9.6%. v1 runs list more documentation friction (1.24 vs 0.72 entries per run, p = 0.0001; 1.28 vs 1.02 among unlabelled runs). Observational and preliminary: task labels differ between arms and seven metrics were tested uncorrected.

An Opus run costs about 8–9× a Sonnet run in the same track (process 7.9×, bootstrap 6.7–11.7; research 9.1×, 3.7–12.1 on only 3 Opus runs). The ledger holds 12 priced Opus runs against 342 Sonnet runs, confounded with date and task, so value per dollar cannot be compared yet: detecting a 50% difference in projects per run needs about 129 runs per arm. Preliminary; cost only.

Of 1,564 run records, 203 (13%) list a deviation from the brief, mostly review (59%) and ventures (27%) runs. Within track, deviating runs take about 1.6× as long and cost about 1.2× as much (stratified permutation p < 0.001), but the cost gap rests mainly on the long process track (1.07×, p = 0.052 without it), and deviating runs end partial 5 points more often. Observational and self-reported: preliminary.

Of 1,638 run records, 882 carry both a cost and a tool-call count. Cost per call is almost constant (median $0.031, 10th to 90th percentile $0.026 to $0.038); a log-log fit has R² 0.91 and misses held-out runs by a median of 9% (90th percentile 25%), no better than a flat cost-per-call multiplier. The pooled slope of 1.22 (1.18 to 1.26) is partly group mixing: it is 1.10 within Sonnet runs and 0.96 within Opus runs (wide interval). Cost is API-equivalent and derived from the same transcript as the call count, so the fit checks the measurement, not agent behaviour. Preliminary.

Of 1,659 run records, 893 carry per-token-kind usage as well as cost and tool calls. At API-equivalent list prices, cache reads are a median 45% of a run's cost, 1-hour cache writes 41% and output 13%; fresh input is about zero. A linear context model fits the cache-read tokens per request as about 60,000 tokens at the start plus about 1,900 tokens more per request (bootstrap 95% interval 1,500 to 2,200), so at the median run (20 requests) the starting context is 76% of what each request re-reads. That fixed part, written once and re-read throughout, is why cost rises with a log-log slope of 1.16 against requests and 1.22 against tool calls rather than 2. Limitations: API-equivalent dollars from list prices, not a bill; the context model explains only 31% of the per-request variance; descriptive, from one repository's runs.

Of 621 run records that count tests added, 84 (13.5%) add none, mostly research runs. Within track and recording regime they end partial 4 of 84 times against 16 of 537 for runs that add tests: a +2.6 point difference, permutation p = 0.23, so no detectable effect (only 20 partial outcomes exist, so power is low). They cost less (median $0.56 against $0.99 in research), most likely because they do less. Observational and self-reported; preliminary.

Of 1,606 run records, 213 list a deviation. Classifying each by fixed keyword rules, runs whose deviation is a tooling failure end partial 22.6 points more often than runs with no deviation within track (permutation p = 0.001, 24 runs in usable strata); skipped steps (+1.3 points, p = 0.67) and switched tasks (+1.3 points, p = 0.63) show no difference. Keyword classes are crude and the data observational: preliminary.

Counts which fields are present on each of the 1,362 run records in prompts/runs/ (1 to 19 October 2026). cost_usd, tokens and wall time are present on 47% of records (Wilson 45% to 50%), but on 0% to 7% of records on 13 to 15 October and 61% to 82% from 16 October, so the rate is a date effect. merged is filled on 4.6%, a pull request is named on 81.2%, and 237 of 1,279 records with outcome success (18.5%, 16% to 21%) name none. Preliminary: presence is measured, not correctness, and an empty list can mean a clean run.

Joins cost to tests added across the 157 priced run records that report adding tests (14 to 20 October 2026). Pooled, the two rank together (Spearman ρ +0.57, bootstrap 95% interval +0.44 to +0.68), but inside a track the link is weak for research runs (ρ +0.19, −0.02 to +0.39; log-log slope +0.33, so doubling cost adds about 26% more tests) and imprecise for ventures (ρ +0.39; slope +1.19, interval +0.48 to +1.88). The dearest third of runs yields the fewest tests per dollar (3.7, against 5.4 and 6.0). Preliminary: tests added is a crude, self-reported output proxy that only 21% of priced records fill in, and the pooled figure partly reflects the track mix.

Joins the 366 run records (14 to 18 October 2026) that carry an API-equivalent cost_usd to the pull-request numbers in the subject lines of main's first-parent history. 273 (75%, Wilson 70% to 79%) name a merged pull request, 1 names one not on main and 92 name none. A merged run costs $1.26 on average (bootstrap 1.08 to 1.49) against $0.94 per priced run, because 19% of spend sits on runs with no merged PR on record; process runs cost about 2.4 times a research run per merged run. All 34 red-team records omit their PR although red-team PRs are on main, so their 0% is a recording gap. Preliminary: five days, one model, API-equivalent cost, and cost per merge is not value per merge.

A stdlib reader of 517 commits touching research/<slug>/ (396 projects, 2026-09-28 to 2026-10-15) fills in what the run log lacks. All 157 projects created since 2026-10-13 are in the log; the 217 it never lists were made in two bulk days (09-29 and 09-30) before the log began. Half of all projects (49%) sit in follow-up families, creations arrive in bursts (median gap 4 minutes), and only 6 of 234 fully observed projects (2.6%, 95% interval 1% to 5%) have a later commit whose subject says it corrects something, a lower bound on defects, not an estimate. No tokens, cost, pull request or CI data; preliminary.

A three-level value rubric (follow-up, new question, listed milestone) scored over all 408 research/ projects by two automated passes, one from names and order and one from README text, plus a blind 30-project hand sample. The two automated passes agree at chance level (linear Cohen’s kappa 0.07, 95% bootstrap 0.01 to 0.13); a flaw in the name pass (108 *-twin projects counted as one follow-up chain) explains part, and fixing it after the fact lifts kappa to 0.25. Against the hand sample the text pass reaches 0.45 (0.24 to 0.65) and the fixed name pass 0.57 (0.24 to 0.81), n = 30, scored by the rubric’s author. Follow-ups add about as many lines as new projects (median 318 vs 328), so by the rubric they return less per line, a ratio that is largely built in. Preliminary and negative on the automated passes; no correctness term.

Three stopping rules for a champion-versus-candidate brief experiment were simulated on outcome distributions drawn from the run ledger (success rate 237/244) and from swe-value’s project values: one look at the end, a look after every pair, and a mixture sequential probability ratio test. Looking after every pair declared an identical brief different in 21% of 2,000 experiments on success rate and 40% on value (nominal 5%); the mixture test stayed at 0.4% and 3.9%, at the price of power (92% against 99% at a +0.2 shift in value, stopping after 181 of 400 pairs on average). At a 97% success rate a fixed test needs about 2,200 runs to see a 0.971 to 0.991 change, so success rate is a poor primary metric. Stylised and preliminary: all 244 ledger rows are the same prompt, effects are hypothetical, and the value scores are weak; no candidate brief has been run.

Four track-allocation policies (uniform, greedy value per line, bootstrap Thompson sampling, and a knapsack-style UCB) were replayed offline on 7 tracks, using the 408-project scores from swe-value (value 1 to 3, cost in lines added) under a 20,000-line budget and 300 seeds. Greedy and Thompson reach about 79–83% (pass A) and 75–79% (pass B) of the best-single-track oracle, against 58–60% for the current uniform pick; the UCB variant explores too much to help (62–66%). This is a stylised, preliminary result: arms are assumed stationary, yet value per line falls with order in 4 of 7 tracks (Spearman −0.36 to −0.57), the value scores themselves agree only weakly, lines are a poor proxy for tokens, and no live trial was run, so no policy is adopted.

swe-decay replayed track-picking policies on one history, so its intervals ignored history uncertainty. Here each track’s sequence is block-bootstrapped (200 histories). At a 20,000-line budget greedy and Thompson beat the uniform draw in 98–100% of histories, with 95% intervals excluding zero (pass A: +33.4 and +30.8 value points; pass B: +26.7 and +23.5); knapsack-UCB’s interval includes zero. The small-budget loss seen in swe-decay does not reproduce under resampling, so it belongs to the observed order. Stylised and preliminary: resampling removes the within-track trend, value scores agree weakly, lines proxy cost, no live trial, no policy adopted.

swe-allocate replayed four track-picking policies with projects drawn with replacement. Here each track yields its next project in commit order and runs dry, using the same scores. At a 20,000-line budget greedy and Thompson keep most of their lead over the uniform draw (pass A: 134.0 and 129.9 against 114.0; pass B: 107.0 and 112.5 against 101.3), reaching 82–97% of a hindsight-greedy reference. At 5,000 lines the smarter policies lose to uniform (24 against 30 in pass A) because two forced pulls per track eat the budget. Stylised and preliminary: weak value scores, lines as a cost proxy, one history, no live trial, so no policy is adopted.

A seeded sample of 40 research/ projects with a runnable experiment was re-run on a clean copy and diffed against the committed results.txt. 36 of 40 (90%, 95% Wilson interval 77% to 96%) reproduced: 34 byte-identical and 2 differing only in a timing line. Three timed out at 300 s (four jobs in parallel) and one needs a voice model that is not in the repository, so those four are inconclusive, not failures. Of 713 decimal numbers in the sampled READMEs, 85% appear verbatim in committed result files (the rest are derived or in prose). A second sample of 60 (8 overlapping) brought the pooled total to 92 distinct projects: 81 reproduced (88%, Wilson 80% to 93%), none of the 81 finished runs gave different numbers, and the 11 others are missing tools (Yosys, MuJoCo, a voice model) or timeouts. Re-running the five timeouts one at a time (no parallel load) reproduced all five (two differing only in timing lines), lifting the pooled figure to 86 of 92 (93%, Wilson 86% to 97%); the 6 left are missing tools or the voice model. A mechanical reproduction check on a small sample, with no citation audit, so the correctness term is only partly estimated. Preliminary.

Replays pairs of research merges that touched the shared index files within 10, 30 and 60 minutes of each other (67 merges, 2026-10-14 to 10-16) and checks the merged tree against the homepage build’s rules. Of 129 pairs within 60 min, 37 (28.7%) conflicted textually and the other 92 merged with no new inconsistency; none was clean but broken. The same checker found two projects with duplicate README.md bullets since the repository fold-in, which build.py missed; they are removed and the build now fails on duplicates. Preliminary: three days, an approximate replay, and consistency rules rather than the full build.

Joins 122 merged pull requests that touched research/ (2026-10-16 to 10-17) to their real creation times from the GitHub API. The median pull request was open 0.9 min (p90 16 min); 95% merged within 30 min, so the 30 to 60 minute windows assumed by swe-sharedfiles were far too long. Of the 58 that edit a shared index file, 21% saw another shared-file merge land while open (mean 0.40), and replaying each from its real creation time gave a textual conflict in 2 (3.4%, 95% Wilson 1.0% to 11.7%). Preliminary: pull-request lifetime is not branch lifetime, one repository, about 1.5 days.

Adds each of the 122 research pull requests’ first-commit time (GitHub API) to the swe-prlifetime data. Branch lifetime is almost the same as pull-request lifetime (median 1.1 vs 0.9 min, p90 16.1 vs 16.0), because sessions commit at the end of their work; commit dates cannot see the earlier working time. Replayed from the branch start, 3 of 58 shared-index-file PRs (5.2%, 95% Wilson 1.8–14.1%) conflict, versus 2 from pull-request creation. The larger finding: research/PROJECTS.md, not in the earlier shared-file list, was edited by 44 of 122 PRs and conflicts in 5 of them (11%). Preliminary: 1.5 days, one repository.

Scores the title and Question section of each project’s README by word overlap (Jaccard index). Pairs in the same slug family overlap about ten times more than pairs across families: mean 0.078 over 7,552 within-family pairs in 14 families of five or more projects, against 0.008 over 213,181 cross-family pairs. The closest pairs, such as mimic-mmd and mimic-mmdmujoco (0.917), are mostly deliberate one-condition follow-ups. Preliminary: word overlap is not result overlap, and shared vocabulary is partly legitimate.

Measured from git history (101 research merges, 2026-10-14 to 10-16): 64.4% edit both README.md and projects.json, the median gap between such merges is 30.6 min, and replaying a later merge against an earlier one within 30 min gives a textual conflict in 18.6% of 59 pairs (15.3% in a shared file). Branch times are assumed, not measured; textual conflicts only; preliminary.

A stdlib Monte Carlo of start-time collisions among runs that pick from a pool of 11 tracks. Four blind simultaneous starts leave 12.8% of runs redundant (closed form agrees), claim-checking alone barely helps because all runs read before any claim is pushed, a start gap longer than the claim latency drives waste to about 1–2%, and scheduler-assigned slots remove it entirely up to the pool size. Every timing constant is assumed, the pool is uniform, and queueing against usage limits is not yet modelled. Stylised; first step of milestone 5 of track 10.

Measured from git history rather than simulated: 218 merged projects since the tracks were set. Over the whole period the mix is far from uniform (tracks 7–11 are 2–4% each, mostly because they were added late), but after all eleven tracks existed (36 PRs) uniform is not rejected (p = 0.25, low power). Same-track pairs among overlapping PRs are 17.9% against 12.3% expected, and the excess disappears once the drifting mix is controlled for (p = 0.115 within merge days). Preliminary: merged projects stand in for picks, and branch overlap is a lower bound on concurrency.

A stdlib analysis of the creation and merge times of every closed PR here (#1 to #526). 87.5% merged (Wilson 84.3–90.0%), falling from 93.8% for PRs opened by 10-01 to 81.2% from 10-05 on. Median time to merge is 0.6 minutes, 4.3% of merges happen in four same-second batches after long waits, and PRs opened within 10 seconds of another merged only 60% of the time against 92% for the rest. The last is an association, not a cause. No CI, review or closure-reason data, and the timestamps were hand-transcribed. Preliminary third step of track 10.

A cited, growing catalogue of 61 practices from 60 sources (Microsoft’s Nudge reminders for overdue pull requests, Uber’s SubmitQueue merge queue, Sentry’s LOGAF-marked code review, Mercari’s production-readiness checklist, Apollo’s priority displays, Kohavi, Tang and Xu on controlled experiments, Strathern on audit, Perrow on normal accidents, the DevOps Handbook, Reason on layered defences, Vaughan on normalization of deviance, Rigby and Bird, Humble and Farley, Beck, Allspaw and Hammond on Flickr, Parnas, Nygard, Conway, Nagappan et al., Skelton and Pais, Brooks, Fowler, Reinertsen, Toyota, the Rogers Commission, 37signals, Instagram, Google, Microsoft, Facebook, Netflix, Amazon, Etsy, Basecamp, Spotify, Stripe (twice, including its online-migrations post), Shopify, Linear, and postmortems from GitLab and Cloudflare, the SEC’s order on Knight Capital and others), each tagged with company stage, evidence type (four measured, the rest case studies, postmortems, accounts or opinion), the loop element it maps to, how far it transfers to a fleet of agent sessions, and the assumption that does not carry over. The failure reports agree: a safety mechanism or a cost nobody measured before it shipped. Scored against the 1,261-row run ledger, the failure classes runs report are small (0.6–1.6% of runs, self-reported keyword matches), so no practice clears the 5% ceiling as a new proposal: a negative result. Sources were checked by web search only. Eighteenth batch of standing milestone 7 of track 10; the research log below records each batch.

Joins 660 run records that have a start time (1 to 19 October 2026) to how many other runs started within 5, 10 or 30 minutes. Raw, crowded starts look better (error recorded in 9.8% against 21.0%), but that is a day effect: 13 to 15 October had 47–50% error records and few concurrent starts, 16 October on 6–9% and many. Shuffling the crowded label within calendar days finds no detectable difference (12 tests, one p = 0.018 on a 50-run group, not counted), and six-hour blocks of the day show nothing. Preliminary and low power: association only, errors is self-reported, and duplicate work, the cost swe-schedule models, is not in the records.

Reads the 35 review-track pull requests merged on main from 14 to 19 October 2026 and groups those merged within 10 minutes of each other. Six are the second member of a pair (17.1%, Wilson 8.1–32.7%; 22.9% at a 30-minute window), all merged 0.4 to 2.5 minutes apart, so they are sessions that started together. None of the extra pull requests was record-only, but in five of six pairs both edited prompts/derived/runs.json or prompts/experiments.md, so the later merge resolved a conflict. Only 3 of 35 review PRs have a priced run record, so the cost of the duplication is not measured. Descriptive and preliminary: six days, merge time stands in for start time.

Checks the run records against the commit history on main. All 522 records that name a pull request in this repository name one that landed (Wilson 95% 99.3–100%). But only 79.8% of sessions that landed commits from 13 October have a record (1,465 of 1,836; 77.9–81.6%): 89.8% of sessions that followed the master prompt, 4.2% of those that did not, and by track research 92.2%, process 93.2%, red team 100% and ventures 79.2% (75.5–82.5%). Coverage rose from about 60% on 13–14 October to 82–88% afterwards. Preliminary: seven days; sessions are identified by a commit trailer, so sessions without one are invisible; landed is a git fact, not a quality one.

Splits the 515 ventures sessions that landed commits from 13 October by prompt version, scope, size, subject and day. 79.6% have a run record against 92.2% for research, and no feature of what the session built separates the unrecorded ones (one venture 80.2%, 1–5 files 78.9%, single commit 80.3%). The one structural difference is in the prompts: every other track's sub-prompt tells the reader to write the record, and the three ventures sub-prompts do not; but ventures/2, which also omits it, reaches 85.4%, and coverage rose from 53% on 14 October to 84–89% on 18–19 October. Preliminary and observational: six days, landed sessions only, no intervals on the day-matched odds ratios.

A hand-labelled census of 80 randomly sampled project summaries (of 711): 51% descriptive, 20% positive, 18% mixed and 11% negative. Among the 39 that test a claim against an alternative, 59% (Wilson 95% 43–73%) report a negative or mixed result, so the portfolio is not a list of wins. A keyword rule for negative or mixed has precision 0.60 and recall 0.65 in-sample and should not be used for by-theme shares. Preliminary: one labeller, one pass, rubric fixed while labelling, summaries truncated when long, no inter-rater agreement.

A reference graph of 723 research READMEs, from slug mentions and git creation times: 61.7% of projects (Wilson 95% 58–65%) are named by at least one later project, but inbound counts are very uneven (Gini 0.69; the most-named is named by 50) and 71% of references stay within a track. Preliminary: a README naming a project does not show it was reused, so this is an upper bound on “built on”; one snapshot, no hand-checked sample of edges.

Joins 1,004 priced agent-run records (46 Opus, 958 Sonnet) and compares the models inside matched strata (same date and track, 11 strata with both), because pooled medians confound model with task mix. Matched, an Opus run costs 6.3× as much (95% bootstrap CI 4.7–8.0), makes 3.2× the tool calls, takes 6.3× the wall time and costs 2.0× per call, because it reads 1.9× more cached context per call. Against the run's own estimate of the human hours it replaces, Opus costs 1.4× more per hour (1.1–1.7). Costs are API-equivalent list-price figures, not charges; the human-hour estimate is the agent’s own and low-certainty; Opus runs are 46 and not randomised, so task difficulty can still differ inside a stratum. Preliminary: six days of data.

Run cost is what limits the loop's throughput, so a rising cost per run would eat the budget silently. This project fits a Theil-Sen trend (the median of pairwise slopes, robust to the long cost tail) to log cost, log cost per tool call and log tool calls against start date, with a percentile bootstrap over runs, for 1,053 run records that carry cost_usd, tool_calls and a start time. Pooled, cost per run rises 3.4% a day (95% interval +1.2 to +5.1). That is a research effect: research runs (456) rise 4.9% a day in cost (+2.8 to +7.0) and 5.7% a day in tool calls (+3.9 to +7.8) while cost per call is flat (−0.5%, −1.1 to +0.1), so research runs are doing more steps, not paying more per step. Ventures, process, red-team, explore and review runs have intervals that include zero for cost per run. The median research run cost $0.88 on 16 October and $1.05 on 21 October. Limits: six calendar days, of which 21 October is partial; observational, so the data cannot say whether the brief, the portfolio's growth or the task mix caused the rise; cost is API-equivalent from tokens, not a bill; the bootstrap treats runs as independent although concurrent runs share a day.

swe-decay found greedy and Thompson track allocation losing to uniform at a 5,000-line budget (24 against 30 value points) because two forced pulls per track ate it. Here each track is pulled once, or a shrinkage rule uses no forced pulls. On the observed history one pull each removes the loss (pass A: 33.0 and 33.3 against uniform 30.0) but costs a few points at 20,000 lines in pass B; shrinkage greedy is no better than uniform on the observed order, matches the others on resampled histories, and is insensitive to its prior size. On 200 block-bootstrapped histories every start rule’s 5,000-line interval over uniform still includes zero. Stylised: lines of code stand in for cost, the value scores agree weakly, and no live trial was run.