Archive complexity accretion audit

.agents/context/2026-08-15__autonomous-complexity-brake-draft.md

@@ -0,0 +1,127 @@
+# Autonomous complexity brake — Fable draft, revision 4
+
+Semantics settled through discussion 07, language pass in 08, discussion 09
+applied in revision 2, discussion 11 in revision 3, and discussion 13's
+surgical correction applied here: the tie-break selects which verb's test
+applies instead of deciding outcomes, and its universal claim is gone.
+Nothing lands until the parallel-slices claim vocabulary settles.
+
+## Proposed `AGENTS.md` replacement
+
+```markdown
+## Complexity brake
+
+During implementation or review, brake before making a proposed change when
+any of these is true:
+
+- a defensive concern already addressed in the current slice comes back
+  extended — another encoding, race, retry, lock, failure record, provenance
+  check, or compatibility case;
+- the change introduces a persistence layer, protocol, background process,
+  ownership state, retry state, or compatibility path for a scenario not
+  shown in supported use;
+- review-driven safeguards have doubled the original change or outgrown the
+  behavior they protect.
+
+A slice is one claimed unit of work; an issue may carry several in parallel,
+and the brake's counter and boundary belong to the slice, not the issue. The
+recorded boundary — the acceptance criteria and exclusions claimed for this
+slice — decides what belongs to it. Supported use is what the product
+actually does for its users and agents: the boundary can put a reachable
+scenario outside the slice, but cannot make it unsupported.
+
+Name the facts of the concern — who can cause it and what they control, what
+breaks, how it is recovered, what the safeguards so far have cost, and the
+smallest change that would help — then give it one verb:
+
+- **fix** the smallest thing, including simplifying or rolling back a
+  safeguard, when the scenario is reachable in supported use, the consequence
+  is material, and prevention is cheaper than recovery;
+- **narrow** an open-ended promise to the finite behavior this slice can
+  prove;
+- **defer** work with real value that belongs outside the slice; or
+- **decline** a concern that needs an actor, variant, or interleaving the
+  boundary excludes.
+
+Where the boundary crosses supported use, the tie-breaks are narrow: a
+regression this change causes in supported behavior is judged by the fix
+test on either side of the boundary; defer takes out-of-slice value the
+change leaves working; and a boundary exclusion alone never declines a
+supported scenario.
+
+The brake changes the verb, not who is driving: when the boundary determines
+the disposition, decide, record, and continue. The record is at most two
+sentences — the concern, the verb, and the boundary clause that decided it —
+in the review reply when one exists and in the normal report. When no
+boundary is recorded, state the one you are using before the defensive
+change. Ask the user only when the boundary does not decide: a reachable,
+material scenario remains, and choosing among the cheapest valid verbs would
+set product behavior the user has not chosen, accept risk to primary user
+data, or widen the authorized scope. Send the resumable state with the
+question.
+
+An open-ended promise needs a finite completion test — evidence whose
+exhaustion ends the concern; a concern without one is narrowed. A concern
+the brake has already caught once in this slice is also narrowed when it
+comes back: one follow-up variant of a safeguard is ordinary work, but a
+third variant is a ladder, and ladders have no top rung. Only a completion
+test recorded before the extensions began exempts a concern — that one is a
+bounded list; finish the list.
+
+A reviewer's severity or “actionable” label ranks a finding; the boundary
+decides it. A finding with a reasoned verb is finished. Seek another
+automated review only when a new head needs one, never to make a finished
+finding disappear or to reach terminal-clean.
+
+Prefer prevention for primary user data, real trust boundaries, and
+destructive operations. Prefer detection and recovery for secondary,
+reconstructible, or disposable state.
+```
+
+## Matching `babysit` changes
+
+Replace the stage-3 tripwire paragraph with:
+
+```markdown
+Read every finding the completed review delivered and sort the whole set;
+when a finding meets one of the brake's triggers, the brake chooses its verb.
+Then push one batch.
+```
+
+Replace the whole finding-round paragraph in stage 4 with:
+
+```markdown
+Three finding-bearing rounds against one boundary are the freeze threshold.
+Every fix and every file-changing narrow creates a new head and therefore
+opens the next round; a rebase, an infrastructure rerun, or required
+housekeeping that draws no findings does not count. After the third round,
+the boundary freezes: narrow, defer, or decline what remains against it,
+adding no further review-driven safeguard or fold. A demonstrated defect in
+supported use still gets fixed. Disposition every later current-head review
+against the frozen boundary rather than searching for a no-issues verdict.
+Report to the user when a surviving finding cannot be dispositioned without
+exceeding the boundary: name the finding, the clause it crosses, and the
+real choices.
+```
+
+## Intended behavior
+
+Speculative hardening no longer stops the thread or asks for a rubber stamp:
+the agent brakes, names the facts, gives the concern its verb, and keeps
+driving. Ordinary findings keep babysit's ordinary sort; the brake takes only
+the findings that meet its triggers. The counter and boundary are scoped to
+one slice, so parallel slices on one issue count nothing against each other.
+The user is asked only for genuinely undecided choices; a routine
+supported-use fix proceeds, before and after the freeze. In `babysit & merge`
+mode, reasoned narrow, defer, and decline dispositions authorize the merge
+once the pull request is green, with no further user turn.
+
+## Landing checks
+
+- Promote only after the parallel-slices refactor settles the claim
+  vocabulary; then verify "acceptance criteria and exclusions claimed for
+  this slice" names the actual persisted fields, and that babysit completes
+  only the merged slice's claim.
+- The rename ripple from discussion 06: `complexity-accretion/README.md:69-79`
+  still describes the pause; one-word `tripwire` pointers remain in the
+  promoted `start-issue` skill and the shared context.

.agents/context/2026-08-15__start-issue-parallel-slices-refactor-brief.md

@@ -0,0 +1,109 @@
+# Brief for Opus — restore parallel slices in `start-issue`
+
+Refactor the canonical `start-issue` skill so separate slices of one issue can
+run concurrently. Preserve its concise five-stage shape and its simple
+detect-and-pause coordination model.
+
+## Source of truth
+
+Work from a fresh branch rooted at `origin/main`. The canonical skill is
+`origin/main:.agents/skills/start-issue/`; this archive worktree's tracked skill
+and `.agents/skills/start-issue-rewrite/` are historical copies, not patch
+bases.
+
+Read:
+
+- `origin/main:.agents/skills/start-issue/SKILL.md`
+- `origin/main:.agents/skills/start-issue/references/work-item-routing.md`
+- `origin/main:.agents/skills/babysit/SKILL.md`
+- `origin/main:.agents/skills/babysit/references/merge.md`
+- `.agents/skills/start-issue-rewrite/rewrite-context.md`, especially sections
+  1, 2, 7, 9, and 15–16
+- `.agents/skills/start-issue-rewrite/discussion-06-codex.md`
+- `.agents/skills/start-issue-rewrite/discussion-08-fable.md`
+- `.agents/skills/start-issue-rewrite/discussion-09-opus.md`
+- `.agents/context/complexity-accretion/README.md`
+
+## The regression
+
+The promoted rewrite says:
+
+- “Add no second claim.”
+- “One item carries one active intent.”
+- Any claim whose phase is not `completed` is active.
+- An issue's claim completes only when the issue closes.
+
+Together those rules serialize an entire multi-slice issue. Issue #97 exposed
+the failure: an active `remove-tabs-show-review-ids` slice prevented another
+thread from starting a separate slice. The user normally runs three to five
+Markover threads and explicitly wants different pieces of the same roadmap
+issue to progress in parallel.
+
+The rule was intended to stop duplicate ownership of one slice. It accidentally
+turned the issue into a lock. This contradicts the rewrite brief's operating
+reality: several agents may work on different pieces at once, while the user is
+available to resolve a plausible collision.
+
+## Required behavior
+
+- Treat a claim as ownership of one bounded slice, not ownership of the whole
+  issue.
+- Allow multiple active claims on an issue when their boundaries and touch
+  points are clearly separate. Proceed without asking merely because another
+  claim exists.
+- Preserve the continuation/takeover/different-item question when an existing
+  claim appears to describe the same slice.
+- Ask when two proposed slices plausibly overlap and the live evidence does not
+  resolve whether they collide.
+- After publishing a claim, treat another active claim as a collision only when
+  the slices overlap or may overlap. The number of active claims alone is not a
+  collision.
+- Keep one active claim as the normal rule for a pull request, because a pull
+  request represents one slice.
+- Complete a slice's claim when that slice finishes, even if its parent issue
+  remains open. Keep the issue and its Project status `In Progress` while other
+  issue work remains.
+- During merge, complete only the claim belonging to the merged slice. Leave
+  other active claims on the parent issue untouched.
+- Keep each run editing its exact claim comment rather than replacing or
+  rewriting another slice's claim.
+
+The ordinary outcomes should be:
+
+1. Same issue, clearly disjoint active slice: create this slice's claim and
+   continue.
+2. Same issue, clearly the same slice: continue it, take it over, or choose a
+   different item with the user's direction.
+3. Same issue, plausible overlap: show the overlap and ask.
+4. Same issue, concurrent publication of disjoint slices: both may continue.
+5. Same issue, concurrent publication of overlapping slices: at least one run
+   detects the overlap and pauses before implementation.
+6. One slice merges while the issue stays open: its claim becomes completed;
+   sibling claims and the issue's `In Progress` state remain truthful.
+
+## Complexity boundary
+
+Use the existing visible comments, slice boundaries, touch points, branches,
+and one bounded post-publication read. Do not restore owner tokens, elections,
+timestamp winners, self-demotion, stable-snapshot loops, locks, retries, or a
+new coordination service. Do not require a child issue or placeholder pull
+request merely to obtain a separate claim namespace.
+
+Preserve the current bounded tracker read, direct-PR routing, interview stop
+conditions, Markover routing, and user-facing identity block unless this
+correction directly requires a change.
+
+## Validation surface
+
+Update only the tests and eval material that encode the serialized rule. The
+known direct assertion is
+`origin/main:test/start-issue-evals.test.ts` under “duplicate claims are
+detected and handed to the user without an election.” Cover both sides of the
+new boundary: disjoint claims proceed, overlapping claims stop. Keep the corpus
+small; this regression does not justify a new protocol or a large scenario
+matrix.
+
+Complete the refactor when the six ordinary outcomes above follow from one
+coherent claim lifecycle, babysit's merge handoff cannot complete a sibling
+slice, and the old one-active-claim-per-issue rule is absent from both guidance
+and tests.

.agents/context/complexity-accretion/README.md

@@ -0,0 +1,111 @@
+# Shared context after the complexity-accretion audit
+
+Read this file and the file for the thread's thrust. They replace inherited
+conversation history when starting a new thread or after context compaction.
+The source reports remain authoritative for detail; these files preserve the
+decisions and user context that are easy to lose.
+
+When a material decision or current state changes, update that thrust's file in
+place. Replace stale text; do not append a session journal.
+
+## Thread split
+
+- This existing thread keeps the skills rewrite.
+- `markover-now.md` starts the short-term Markover thread.
+- `local-app-hotspots.md` starts the longer-term simplification thread.
+- `lastcode-tooling.md` starts the LastCode and workflow-tooling thread.
+
+## User goals and operating constraints
+
+- Markover must remain personally useful. Announcement-roadmap work should not
+  displace the tweaks and features that improve daily use.
+- The desired public finish is modest: announce on GitHub and Hacker News,
+  handle likely modest attention, then treat Markover as mostly done except for
+  personally important work, fixes, and contributed PRs.
+- The project also exists to learn open-source development and rebuild a
+  professional network after not working since 2019.
+- Complexity accretion is a recurring problem across projects. The working
+  method must notice a blackhole early and escape it.
+- Sustainable capacity is about 4–5 hours per day and 25 hours per week.
+- The user likes tooling and stays engaged with parallel work: normally 1–2
+  heavier LastCode sessions and 3–5 Markover sessions. Fewer than four active
+  sessions creates distracting idle time.
+- At genuine choice points, offer 2–3 valuable alternatives rather than one
+  prescribed backlog.
+- Current daily pain includes a canonical Markover instance that is often stale
+  or broken, and T3Code's awkward handling of `markover:` review links.
+
+## What the blackhole established
+
+Issue #136 / PR #141 asked for a finite metadata-conformance baseline with no
+application code. Repeated automated review silently widened a bounded privacy
+claim into protection against arbitrary representations of private input.
+
+At its high-water mark the PR had about 29,105 inserted lines, 351 fixtures,
+254 commits, and 160 findings. A clean rebuild preserved the useful result in
+1,292 lines and three fixtures. Review still grew that rebuild to 1,757 lines
+through 17 findings, 10 reviews, and nine follow-up commits before merge. The
+final artifact was reasonable; the path remained too expensive.
+
+The mechanism was consistent:
+
+1. an open-ended property had no finite domain or completion evidence;
+2. review severity was treated as authority;
+3. each safeguard created new codecs, states, provenance, retries, or cleanup;
+4. terminal-clean review replaced the issue's acceptance criteria;
+5. cheap recovery and insignificant consequences were ignored.
+
+The reset succeeded when the agent removed speculative provenance and declined
+coincidental-ID and adversarial-symlink hardening. The intended habit is
+proportional judgment, not universal rejection of defensive code.
+
+## Boundary used by every thrust
+
+Protect primary review feedback, attachments, secrets, real renderer/IPC
+boundaries, destructive operations, and the real concurrency where an agent and
+user can touch the same review. Prefer fallback, rediscovery, reset, or ordinary
+retry for secondary, reconstructible, or disposable state.
+
+The canonical tripwire is in `AGENTS.md`. It pauses work when a later finding
+extends an already-addressed defensive concern, unsupported machinery appears
+for an unproven scenario, or safeguards outgrow the behavior they protect.
+Before continuing, establish:
+
+- the reachable actor or interleaving;
+- the material consequence;
+- the ordinary recovery;
+- the complexity already introduced;
+- the smallest alternative; and
+- finite evidence that ends the slice.
+
+## Durable sources
+
+- Audit overview:
+  `doc/explanations/2026-08-13__complexity-accretion-audit/index.html`
+- PR #141 forensics:
+  `doc/explanations/2026-08-13__complexity-accretion-audit/01-pr-141-forensics.html`
+- Guidance failure:
+  `doc/explanations/2026-08-13__complexity-accretion-audit/02-guidance-loop.html`
+- Local-app hotspots:
+  `doc/explanations/2026-08-13__complexity-accretion-audit/03-local-app-hotspots.html`
+- Tooling/process hotspots:
+  `doc/explanations/2026-08-13__complexity-accretion-audit/04-tooling-process-hotspots.html`
+- Start-issue research:
+  `.agents/skills/start-issue-rewrite/rewrite-context.md`
+- Revised issue #97 path:
+  `doc/plans/2026-08-13__issue-97-enrichment-simplification-path.md`
+
+## Session and branch recovery
+
+The current multiply-compacted T3 thread is
+`a6c280a5-d479-4a07-9233-065e765da6f2`. The original #136 blackhole thread is
+`4e6fb032-a168-459f-b704-a3d034b82961`. Their persisted messages are in
+`/Users/lasto/.t3/userdata/state.sqlite`; original provider logs also live under
+`/Users/lasto/.t3/userdata/logs/provider/`.
+
+This directory lives in the worktree for draft PR #151, branch
+`agent/archive-complexity-accretion-audit`. PR #151 is a dormant evidence and
+process archive, not an implementation checklist or announcement dependency.
+Product recommendations leave it as standalone PRs.
+
+Snapshot date: 2026-08-13 PDT. Recheck live PR and branch state before acting.