This is the record of an abcd-managed repository

abcdBetav0.16.2 · 2026-11-06

Development record

An Intent Is Decomposed Before It Is Filed, And A Reversal Is Only Ever Flagged

disciplinedisciplinesmajordisciplineitd-84

Rule

At /abcd:intent capture, before an intent is filed, a validator produces an advisory analysis a human confirms. One proposal is rarely one record; capture routes the pieces, it never files a monolith.

  1. Decomposition. Each part of the proposal is routed to its record home — user-facing capability → an intent; trust-boundary rule → an ADR (+ a brief invariant); standing stance → a principle; plumbing → the brief. The output names, per part, its type and its home.
  1. Interdependency. The existing records the proposal touches, overlaps, duplicates, or reverses are surfaced — found by a deterministic candidate pass (a lexical shortlist over the record corpus), then reasoned over. Cross-record links are typed — supersedes / reverses / duplicates / refines — never a vague "related".
  1. A reversal is advisory-only. "This reverses invariant X" is flagged for a human to confirm — never auto-classified, never auto-filed. Contradiction detection is unreliable even on frontier models and over-flags by default, so the most valuable check is the one that must never hold a gate shut on its own.
  1. The verdict has three outcomes, not pass/fail — e.g. FILE-AS-IS / SPLIT / HOLD — with a sample-size floor (thin evidence never auto-routes), a safety veto (a hard structural violation forces HOLD regardless of score), and windowing per (target, prompt_version) so a prompt change cannot silently drift the calibration.
  1. Deterministic-first, semantic-host-delegated. The always-on pre-pass is plain Go: a lexical shortlist plus an atomicity smell that flags a proposal naming several distinct capabilities as a SPLIT candidate — no model. The semantic decomposition and reversal reasoning are a host-delegated agent over the small candidate set. Embeddings are an optional adapter, never a runtime dependency.
  1. The validator is a verdict-rendering agent, so it inherits itd-81: calibrated against a labelled corpus, a declared true-negative-rate floor, every finding carrying a failure scenario. It is independent of the proposer (evaluator-outside-the-loop); the human adopts the routing (verifier-selects-gates-decide).

Build path (promotion ladder). The decompose-before-filing principle, the documented decomposition protocol (the hand-run four-piece table), and the deterministic Go pre-pass are the MVP rung — build first. The automated capture-time agent is the discipline rung — build after the protocol is calibrated against ~50 real, human-graded captures. Until the agent ships the gate is the documented protocol, announced as not-yet-automated (loud-staging).

Delivered rung: the capture-time candidate pass. The lexical shortlist of rule 2 runs at filing, delivered by itd-2609212137116617: capture and the quoted-text intent create match the new text against every open and resolved issue and every intent, write each likely double onto the new record as a typed duplicates or refines link, never refuse the write, and leave the link for a human to confirm or remove. It proposes no reverses and no supersedes, so rule 3 holds by construction. The atomicity smell, the per-part routing, the reversal flag and the three-outcome verdict are not delivered, and the hand-run protocol stays their gate.

Why

The record information architecture (adr-30) already supplies typed homes — intents, ADRs, principles, disciplines, the brief. The failure mode is filing a monolith into one of them: the 2026-07-13 auto-merge intent review found one "feature" (--auto-merge) was four record types — an experience (intent), a trust rule (ADR + invariant), a stance (principle), and plumbing (brief) — and only one was an intent. Naming the decomposition as a capture-time gate makes that routing deliberate instead of accidental.

The mechanism is rooted in SOTA (../../research/notes/2026-07-13-intent-decomposition-sota.md), which bifurcates sharply and dictates the shape above:

  • Deterministic candidate-finding is mature. Linear ships embedding+cosine similar-issue detection advisory, at issue-creation ([linear]); a plain-Go lexical shortlist is the always-on floor, embeddings the optional seam.
  • A deterministic pre-pass carries real load. Paska hits 89%/89% on requirement smells with pure NLP ([paska]) — "is this several records?" is a cheap structural check, no LLM.
  • Semantic routing is usable-with-a-human. Diátaxis classifiers already flag a blended artefact so it can be split — the decomposition behaviour, for a 4-way taxonomy.
  • Contradiction/reversal reasoning is research-only ([coinflip]; ContraDoc): unreliable even on GPT-4, over-flagging is the dominant failure — hence rule 3, advisory-only.
  • The advisory-gate pattern is adoptable wholesale ([gate]): three outcomes, sample-size floor, safety veto, per-version windowing — rule 4.

This subsumes the unbuilt intent_sota gate. itd-29 gestures at a lint that would enforce that every intent declares its SOTA (the sota-per-intent principle). Enforcing SOTA-rooting is simply one check this validator runs — the reminder that a design decision must be rooted in SOTA and the mechanism that enforces it are the same family: capture-time automated analysis.

It also embodies facilitator-default-thinker-optional (landing in the auto-merge groundwork change): the validator's default output is the facilitator decomposition table + interdependency list; the press-release framing is the optional layer, never the headline.

What's In Scope

  • The record-home taxonomy and the per-part routing.
  • The deterministic Go pre-pass: lexical candidate-finder + atomicity smell.
  • Typed cross-record links (supersedes / reverses / duplicates / refines).
  • The advisory three-outcome verdict with a false-positive budget, sample-size floor, safety veto, and per-(target, prompt_version) windowing.
  • SOTA-rooting as one check the validator runs (the sota-per-intent enforcement the unbuilt intent_sota gate wanted).

What's Out of Scope

  • A bespoke contradiction/reversal detector as a reliable gate. SOTA: research-only. It stays strictly advisory and human-confirmed.
  • Any blocking gate or auto-filing. The verdict is a proposal; the human adopts it.
  • Reinventing vector storage or semantic similarity. Lexical is the default; embeddings are an adapter to an existing service, not Go we write.
  • Formal RTM / traceability tooling, DSM/goal impact-analysis machinery, Controlled-Natural-Language authoring, and off-the-shelf NLP4RE libraries — anti-fit or non-existent-as-a-drop-in (the field is 44.6% unlicensed).
  • Training or fine-tuning a classifier model — a heavy dependency for a task an agent does zero-shot.

Acceptance Criteria

BDD format, per the itd-1 discipline.

  • Given a proposed intent at capture, when the validator runs, then it emits a per-part routing (each part → its record home), and nothing is filed until a human confirms it.
  • Given a proposal naming several distinct capabilities, when the deterministic pre-pass runs, then the atomicity smell flags it as a SPLIT candidate — without invoking an LLM.
  • Given a proposal that touches existing records, when the candidate-finder runs, then related records are surfaced by lexical shortlist and presented with typed-link suggestions.
  • Given a possible reversal of an existing invariant, when the validator raises it, then the flag is advisory and requires human confirmation — never auto-classified, never auto-filed.
  • Given the validator's verdict, when it renders, then it is one of three outcomes (not pass/fail), respects a sample-size floor, and a hard structural violation forces the negative outcome regardless of score.
  • Given the validator is a verdict-rendering agent, when its spec closes, then it is calibrated per itd-81 (corpus, TNR floor, findings carry a failure scenario).

Open Questions

  • Where the deterministic/semantic boundary sits. How much the atomicity and overlap smells catch cheaply before the agent is invoked — resolve empirically once the pre-pass runs on real captures.
  • The taxonomy enum. Is discipline a routing target distinct from principle? Where exactly does a trust rule split between an ADR and a brief invariant? Derive from graded real captures, not front-loaded.
  • Does the pre-pass run in preflight? Leaning: the deterministic pre-pass is cheap enough for capture-time; the semantic agent is the expensive async tier (the itd-81 harness question, same shape).
  • Corpus construction. Inject from our own history — past intents that should have been split (the auto-merge review is case one) — mirroring itd-81's harvest-from-fix:-commits recipe.

Dependencies

  • Hard prerequisite: itd-1 — this discipline's acceptance gates use its Given-When-Then shape.
  • Inherits: itd-81 — the validator renders verdicts, so it is calibrated (corpus, TNR floor, failure-scenario admissibility) under the judge-calibration discipline; it must never become a blocking gate.
  • Enforces: the sota-per-intent principle — this validator subsumes the unbuilt intent_sota gate itd-29 gestures at.
  • Embodies: the facilitator-default-thinker-optional principle (landing in the auto-merge groundwork change), plus evaluator-outside-the-loop, verifier-selects-gates-decide, and script-first-mvp.
  • Routes into: adr-30 — the record IA is the taxonomy the decomposition routes each part into.
  • Related: itd-79 — the two-role framing the facilitator/thinker principle generalises.

Audit Notes

Empty. Populated by intent-auditor's single-document role when this discipline is first audited. Like itd-1, itd-5, and itd-81, audited continuously via rule-applies-to-every-capture semantics rather than a planned→shipped transition.

References

Frontmatter

iditd-84
typeintent
lifecycledisciplines
kinddiscipline
severitymajor

.abcd/development/intents/disciplines/itd-84-intent-decomposition.md
open on GitHub ↗ · commit history ↗

References1

  • itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Themblocked by

Referenced by6

  • iss-2610262033577968itd-84 calls the intent_sota gate unbuilt; the intent surface lists intent_sota as an armed record-lint rule at warnrelated
  • iss-2610262036101369itd-84 types a proposal's relation to existing records as supersedes/reverses/duplicates/refines; ideate's record grill types the same relation as covered/contradicted/superseded.related
  • iss-2610262042351798itd-84's validator inherits itd-81 yet renders a three-outcome verdict; itd-81 requires binary verdictsrelated
  • iss-2610262042503210itd-84 says model contradiction detection must never hold a gate shut on its own; itd-2609291923559186's hook can refuse a commit on onerelated
  • itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kindrelated
  • itd-2609212137116617A new capture or draft is matched against the record before it is writtenbuilt on by

mentions48

  • adr-30Design-record information architecture — flat artefact-type folders
  • adr-38Implicit checks are disk-only — the network answers only an explicit ask
  • adr-44abcd never mutates a remote uninvited, and identity derives from caller-local facts
  • adr-46Persisting the hook binary never weakens the verification posture — every promotion re-verifies, and SessionEnd performs no network work
  • adr-51An intent can declare its mechanism claim and its scope conditions
  • adr-2610030720195401abcd keeps its own folders out of desktop indexing only by changing those folders, never the computer's search settings
  • adr-2610120558328615A private advisory's record never enters the public ledger, its store is never committed, and nothing public carries an advisory id or hint
  • dcn-26081500000000022026-08-15 — itd-84 (intent decomposition) ADOPTED at the MVP rung, per its own staged promotion ladder: the `decompose-before-filing` principle is filed, the hand-run four-piece protocol lives in the /abcd:intent surface page (capture and the planning interview both run it, loud-staged as not-yet-automated), a DECOMPOSITION rules domain injects the rule at recall time, and every hand-run is graded into `.abcd/development/research/notes/2026-08-15-decomposition-calibration.md` (the 2026-07-13 auto-merge SPLIT case seeds the corpus retrospectively). The deterministic Go pre-pass is admitted to the predictable-development plan's queue (front-door design open: `decompose` subverb vs a check in `intent ready`; collision with iss-210 noted). The capture-time agent rung stays DEFERRED until ~50 graded captures exist (itd-81 calibration); building or running it earlier is a recorded STOP. Rejected: overriding the bundled INTENTS rules domain to carry the new rule (a per-field override replaces the whole array and would withhold future bundled upgrades — iss-174's exact failure mode), hence the additive custom domain instead.
  • dcn-26081500000000032026-08-15 — itd-111 planned at the live interview (spc-22 minted, `intent ready` exit 0). The itd-84 decomposition's first live hand-run rendered SPLIT, confirmed: the network trichotomy extracted to adr-38 ("implicit checks are disk-only — the network answers only an explicit ask") + brief invariant 7, which the intent now cites rather than declares; the SessionStart staleness notice vs the iss-206 skew-notice retirement was ruled a SCOPED REPLACEMENT (`refines`, not `reverses`) — steady-state skew machinery stays retired, itd-111 covers dev checkouts and failed provisioning. Interview rulings: explicit check at `abcd version --check` (ahoy stays disk-only); refusal-on-stale deliberately narrow (ahoy install only); unknown vintage (unstamped/dirty builds) is a first-class comparator outcome that fails closed at the refusal gate; harness portability of the session-start channel explicitly deferred to the itd-22 lineage. Independent SOTA fit-challenge UPHELD path 2 with three recorded caveats (seam = version-source provider interface, not a fixed-arity function; git's behind-upstream notice joins the anchors; BuildInfo stamping holes motivate the unknown outcome). AC 6 narrowed to the transition report (the fetch is itd-105/108's); one AC added (unknown vintage). Hand-run graded into the decomposition-calibration note (entry 2).
  • dcn-26081500000000052026-08-15 — Multi-harness support is IN SCOPE, reversing (`reverses`) the "obsolete under no-hard-deps" annotation the 06-delivery out-of-scope index carried on itd-22; the intent stays in drafts/ as the lineage carrier pending rework. The commitment: every supported harness drives the same abcd CLI functionality — behaviour lives once in the transport-agnostic core (adr-23) and is never double-written for one host. Per-harness delivery follows an adaptor ladder, most-native first: (1) the host's own plugin/packaging format, (2) any other native seam (lifecycle/hook wiring, config), (3) an MCP server as the universal fallback floor every MCP-capable host gets when rungs 1–2 are unavailable. Where a host exposes a native work-plane (goal/work-item tracking, a canonical wiki or knowledge base, trajectory judging), abcd's concepts (intents, brief, reviews, capture, lifeboat) map onto those native concepts rather than running as a parallel artefact set; hosts without such concepts get the adaptor rungs without the mapping. Candidate harnesses exist but commitment records name no external tool before per-host adoption is decided (2026-07-30 convention); each host adoption files as its own intent per the itd-22 lineage's own rule. Rejected: the reversed annotation's claim that a second harness is "just another host over the same core" needing no record — the core stays single, but hook/payload portability, packaging, and concept mapping are real per-host work the record must carry. The itd-84 decomposition hand-run routing this into intent/principle/brief rows precedes any filing.
  • dcn-26081600000000012026-08-16 — the multi-harness routing ADOPTED at maintainer confirmation (itd-84 hand-run graded into the decomposition-calibration note, entry 3): adr-39 filed — the host-tier policy (MCP front door as the universal floor; the current plugin host's integration as the reference implementation, the assumed SOTA surface for the time being; the shipping default ultimately an open-source harness, flipping only on the parity suite plus a deliberate maintainer act; adaptor ladder most-native-first; per-host adoption one intent each at an explicit decision, nameless until adopted). itd-22 renamed `harness-portability` (id unchanged) and reworked to carry the shared machinery only — host profile seam, ladder semantics, parity conformance suite — with a retire-the-name ban (`retired-itd-22-slug`) on the old slug. itd-113 minted: the MCP front door intent (the floor is the first build). The never-double-write stance routed into adr-39 rather than a new principle — it restates one-canonical-primitive at the host boundary.
  • dcn-26081600000000072026-08-16 — itd-76 planned at the live interview (spc-31 minted, `intent ready` exit 0). The itd-84 hand-run rendered SPLIT, confirmed: itd-76 narrows to the personal core (source add / ledger / sync-banlist / cite-check + guards); team share/ingest files as itd-126 and paper reconstruction as itd-127 (both `refines` itd-76, seeded criteria marked unconfirmed); the trust rule extracts to adr-41 (proposed) + brief invariant 9 — documents and ledgers never leave the user tier, a public citation requires both gates — which the intents cite rather than declare; the stance files as the consult-freely-cite-deliberately principle. Interview rulings: the share surface is the existing `.abcd/development/research/references.csl.json` research store, not a second `.abcd/work/references.json` exchange file (one committed bibliography — resolves the store clash the sources-plan adversarial review flagged); the draft's "Dogfood (already running)" claim was stale and is rewritten as target (no corpus on the development machine); multi-machine ledger ownership explicitly deferred until a second machine exists; persona Maya corrected to Alice. Seven Given-When-Then criteria authored and accepted in full. Rejected: planning the monolith (both remaining open questions gated only the share/ingest part), and holding for itd-77 (the corpus default path works without relocation). Hand-run graded into the decomposition-calibration note.
  • dcn-26082200000000072026-08-22 — Interview-workstream records filed (the 2026-08-22 handover's
  • dcn-26102222163464482026-10-22 — The plain-terminal drain is one intent that refines the shipped drain bundle (facilitator, on the product thinker's delegation of 2026-10-14 and 2026-10-16, itd-2610222215485265): the decomposition table routes it FILE-AS-IS, since its fence (itd-2610161621364075), its routed judge's isolation (commands/drain.md) and the consent to start agents are rules already in force, cited rather than restated; it refines itd-2610161016401115, whose press release promised a plain-terminal drain and which delivered the routed judge but no loop, rather than reopening a shipped record; revised after review round 1: the path reverses the host-delegated boundary for an opt-in use, as itd-2609201916151817's decision 5 flagged, so that reversal is recorded as adr-2610222222326104, proposed until the sign-off (grounds: the decomposition-calibration note under 2026-10-22; itd-84)
  • decompose-before-filingDecompose Before Filing
  • iss-344Parallel hunts capture the same defect twice: iss-306 (hunt A round 1, landed late) and iss-339 (hunt B round 2) record the identical githubRemoteRe case-sensitivity bug, minted independently on unmerged branches invisible to each other. Collision-proof ids (itd-114) do not solve this class — it is the semantic sibling of the id collision, sharing the root cause that parallel minters cannot see each other's unmerged mints. Candidate rungs: a capture-time similarity check (itd-84's validator rung), hunt briefings that read open PRs' ledgers, or a shared mint registry as a side effect of itd-114's forge-backed option
  • iss-351the three-disciplines roster itd-1 itd-5 itd-37 is hand-enumerated at six sites while intents/disciplines/ holds six active disciplines, dropping itd-79 itd-81 itd-84 from the mental model, scope, roadmap dashboard and phase-0 acceptance
  • iss-381The delivery pipeline abcd runs on itself is hand-orchestrated and should be deterministic. This session hand-ran the full sequence: SOTA research -> itd-84 decomposition -> draft intent -> TWO independent adversarial reviews (design/feasibility + record-discipline) -> planning interview -> plan+spec -> test-first implementation -> TWO more adversarial reviews of the diff (ruthless + security) -> apply/refute findings -> gates (preflight, record-lint) -> atomic commits + PR -> resolve the ledger issue with provenance -> seed the deferred items back into the ledger. Every hand-off, gate, and review-pair was driven by judgement, not a deterministic harness. The individual stages already have records — itd-83 (the review bar fires itself), itd-84 (decompose before filing), itd-82 (ledger drain), itd-78 (intent-dependency graph) — but ALL are drafts/staged and NONE composes the others into one orchestrated pipeline. Honest constraint (loud-staging): the pipeline cannot be MORE automated than its stages, so full automation waits on those disciplines shipping; but the deterministic SCAFFOLD — the fixed stage order, the mandatory review-pair gate before plan and before merge, the hand-offs to the host for the human-in-the-loop steps, the ledger-seed-the-deferrals close-out — can be built now as a workflow/routine (itd-107 versioned-routine-template is the nearest delivery vehicle). Routing note: this is a big, cross-record idea, not a decomposed intent — it likely needs /abcd:ideate then itd-84 decomposition before it becomes filable, and it may reshape rather than duplicate itd-83/82/78.
  • iss-390the pre-decided promotion of examples-use-reserved-identifiers to a discipline-kind intent never happened — the iss-154 lint shipped, the principles README contract says a mechanical gate promotes the principle, and no discipline intent exists
  • iss-2608230748418054Ideate leg-2 grill has a structural blind spot for id-less records: the 2026-08-23 abcd-research-verb run's grill failed to surface the same-day research note (2026-08-22-sota-research-protocol.md) that answers the submitted idea by name, because research notes carry no citable record id and the grill's output is id-cited hits. The nearest-citable-record note-field rule exists but nothing prompts a sweep of research/notes/ or DECISIONS.md, so a standing verdict recorded outside the id-bearing record families is invisible to the leg that exists to prevent re-litigation. The leg-3 evaluator caught it only by doing its own sweep.
  • iss-2608230752354909Record explorer IA restructure seed (intent-sized, maintainer-proposed 2026-08-23): sub-nav becomes Dashboard (Genealogy graph docked collapsed) / Foundations / Development (intents, specs, issues rendered like Foundations) / Relationships / Health (new page aggregating every deterministic inconsistency: unresolved cross-refs, author-identity duplicate candidates with suggested .mailmap lines, baseline ratchet), with Contributors and References as right-aligned text glyphs (ruled: glyphs, not image assets). Release-cadence panel replaced by a commits-per-release-window ridgeline, designed within this intent. Draft via the itd-84 decomposition gate before filing (reports 3c, 12, 15-amendment, 19-addendum).
  • iss-2608230847432287the adversarial-review floor assumes below-the-line artefacts are covered by their gates, and today they were not
  • iss-2608270550201935Ship an advisory-dedup echo into 'abcd capture': on write, run a NON-BLOCKING similarity scan over open/ issues plus draft intents, and when a strong match is found return it in the capture result (e.g. 'captured iss-N; possible overlap: itd-91, iss-193 — review?') WITHOUT gating the write. This gives the user immediate 'this area is already tracked' reassurance while keeping capture one-line and friction-free — verifier-selects/gates-decide: the tool proposes the overlap, the human disposes (keep / wontfix / promote). Distinct from itd-84's capture-time VALIDATOR (a deterministic pre-pass that decides INTENT decomposition FILE-AS-IS/SPLIT/HOLD, not issue-duplicate detection) and from itd-87 (recurrence-escalation in capture). The deeper cross-corpus combine — merging issue clusters and promoting to intents — is a separate periodic step (e.g. a 'capture list --dedupe' view), not per-capture. Motivated 2026-08-27 by a session that recorded a duplicate of itd-91 and caught it only after the write; until this ships, the documented protocol (agent recall-checks the ledger before recording) is the gate. Candidate for promotion to an intent.
  • iss-2608271817300337ADR seed from the security-advisory pilot's verified trust rules (itd-149 decomposition, part 2): auto-merge arms only after a comprehensive no-bypass required-check set AND an independent adversarial APPROVE, never on CI-green alone (F-N); the two release gates that are human-by-design stay human (F-Q); a verdict is never transferred — every required pass re-runs against the final content commit (F-U). These are trust-boundary rules, not intent scope: file the ADR with its brief invariant, then link itd-149 to it at planning.
  • iss-2609170726457256No verb stamps impact or builds_on on an existing intent draft. --impact exists only on the filing call (abcd intent "<text>" --impact) and again at the close that ships the intent (spec close --impact); between those two points a draft that was filed without a judgement has no verb that adds one, and builds_on, a schema-known frontmatter field the readers walk, has no flag on any verb at all. Relayed from the Gropius managed-repo session gropiusllm-56 on 2026-09-17, where two sessions hand-edited the frontmatter of five drafts with sed to set both fields, which bypasses every validator the verbs carry (ParseImpact, the never-internal rule for intents, the record-id shape of a builds_on target). Confirmed against the v0.9.0 command tree: intent plan takes only --production-mode, intent link writes spec_id only, and no verb names builds_on. Sibling records: iss-126 (resolved) gave impact a home at the close, and iss-2609091256264547 (open) covers the three typed relations the schema lacks; this finding is about the one relation it has and the one judgement it accepts, neither of which a verb can write onto a draft. Intent-shaped by the itd-84 four-piece table (a capability: a draft's judged fields are settable through a verb after filing), so the routing to an intent draft is the human's to confirm; recorded here first.
  • itd-5Every Agent Prompt Carries Its Version, Earns Its Lock, And Survives Injection
  • itd-29Domain Experts Run A Spec Autonomously And Recover From Anything Without Touching Git
  • itd-42Grill Reads an Intent Against the Brief and Its Siblings, Not Just the Glossary
  • itd-79Personas Come From the Registry; the Role Picks the Name
  • itd-81No Judge Ships Unmeasured, And A Clean Diff Is A Result
  • itd-109Acceptance Criteria Verify Themselves, And The Manual Rest Renders For A Human
  • itd-111A Stale abcd Never Answers Silently
  • itd-114Two Agents Can Mint At The Same Instant And Never Collide
  • itd-115A Ready PR Merges Without Ever Wedging BEHIND
  • itd-116Validated GitHub Issues Become Ledger Entries Without Retyping
  • itd-132The hook binary survives plugin updates
  • itd-190The claim recording gradient: an intent's three claim kinds carry three recording requirements, and the readiness gate holds them
  • itd-2609231013154443Every release arrives with a press release composed from what shipped
  • itd-2609231434459890abcd's own tests warn before running on an overloaded machine
  • itd-2610030720038073abcd keeps its home folder out of desktop indexing by default
  • itd-2610031026190632abcd's update check says when a harness is older than abcd needs
  • itd-2610032150577708The product thinker's dashboard, in a browser through Tailscale
  • itd-2610240933025076abcd plans unattended and asks only what a person owns
  • itd-2610261025516272Private repos land checked work without renting CI
  • itd-2610301428378830abcd tells an agent what to do next, after a refusal and after a success
  • spc-2609211918551301coherence-aware-grill
  • spc-2609212141417782a-new-capture-or-draft-is-matched-against-the-record-before
  • widen-options-never-recommendWiden options, never recommend