Skip to content

mcpx: the backlog build-out — every theme, in one order, with the disagreements between them (super tracker) #1900

New issue
New issue
Open
0 of 6 issues completed
Open
mcpx: the backlog build-out — every theme, in one order, with the disagreements between them (super tracker)#1900
0 of 6 issues completed
Assignees
dezren39
Labels
effort/lLarge: multi-day or open-ended; expect staged check-insenhancementNew feature or requestkind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)source/creatorFiled by the new-issue-creator jobstatus/triagedTriaged and routed (see agent note)task/triageQueue packet kind: verify, reproduce, and route this item

Description

@dezren39
dezren39
opened on Oct 28, 2026

Relocated from dezren39/darwin-nix#181 on 2026-10-28 (placement audit): mcpx's single source lives in developing-today/code (pkgs/mcpx); re-home tracked at #309. Original body below; issue references inside it are historical (dezren39/nix numbering).

The whole mcpx backlog in one place: seven category trackers, 111 open issues, what is already done, a proposed
order, and the collisions between themes, each with an owner.

Every open issue in the milestone mcpx: backlog build-out descends from this one through native sub-issue links.
The only deliberate exception is #11 (Renovate's dependency dashboard), which the bot owns.

Revised 2026-09-30 (issues pass, at 05c78b2). Every open issue was re-checked against current main. What
changed here: a Done section; #52, the CI cache line and "no Containerfile" moved to it (all #182); the
static-binary evidence corrected (a CGO_ENABLED=0 build is fully static -- nothing in mcpx blocks it); every
collision given an owner, three of them new design issues (#185, #186, #187); two new bugs from the pass under #177
(#192, #193); the grid and order re-rated from the leaves' own footers; the graph's wrong edges removed (#6 does not
block #81's bus, #78 does not block #88, #88 does not block #87). Issues other architects were changing while this
pass ran are marked in flight.

Categories

Category Tracker Open issues Scope in one line
Testing #91 → #93 #95 #97 #99 28 Fuzzing with one seed per run, integration tests per feature, a sharded CI with a time budget, and the policy for what an agent runs.
Documentation #89 (under #91) → #90 #92 #94 #96 #98 26 The book: a 30-second layer, a manual, a compendium; a site that deploys; reference pages generated from the binary so they cannot drift.
Runtimes, languages, dependencies #175 9 What runs a script, in what language, with which packages -- runtime selection, the dependency chain, import resolution, one cache mechanism, Python, shebangs, flake refs.
The AI layer and search #176 10 Where a model comes from, and what would use one -- search, repair, hooks, admin-by-intent, composed tool sets, connectors -- plus the shared matcher and the settings ceiling they need.
Extensibility #173 6 A plugin is an MCP server; hooks over the event bus; anything as a tool source; embedding mcpx.
Surfaces #174 5 Reaching the daemon over ssh and the browser, and keeping what you reached -- socket discovery, lifetimes, ssh, a web frontend.
A promise and a behaviour that disagree #177 16 The bug class where something declared does not do what it says, and the guard-test pattern that closes it. 15 children, most of them found since the build-out began — nine of the fifteen were filed during this pass.
Pre-existing, no tracker -- 10 #5 #6 #7 #47 #48 #49 #76 #77 #78 #79 -- each a dependency of something above, placed in the order below.

111 open issues in the milestone, 17 of them trackers (this one included). Verified at the end of the
2026-09-30 pass by walking repos/dezren39/nix/issues/<n>/parent for every open issue: all 110 below this
one reach it, and the walk has exactly two roots — this issue and #11. No chain is orphaned and none
cycles.

Children

Six category trackers, and the pre-existing issues that predate the build-out and have no tracker of their own because
each is a dependency of several parts of it.

Done

What this backlog asked for that has already landed. Closed issues stay attached to their trackers as checked items.

Done By What it settled
#52 -- the e2e suite leaked daemons for four hours #182 Cleanup calls stop --all, which finds daemons through their info files, not a recomputed socket path; every test env sets MCPX_AUTOSTART_IDLE_EXIT=60s (internal/e2e/e2e_test.go:68-83). The test was falsified by reverting the fix. No longer blocks sharding.
#135's one-line cache fix (cache-dependency-path) #182 .github/workflows/mcpx.yml:50. The key now saves; no warm run has been observed yet -- the first push to main after #182 was the one that saved it. The rest of #135 is open.
"There is no Containerfile" (#134, #158, #97) #182 pkgs/mcpx/Containerfile, docs/container.md: pinned by tag and digest, debian-slim, ships bun, 413 MB. Not built or tested by CI yet (#134).
Whether mcpx can be a static binary (#136) #182 Yes: CGO_ENABLED=0 gives a fully static, working linux ELF. #136 is now the policy decision about which shipped artifacts should be.
The settings registry declared settings nothing read #171 consumed_test.go's three guards; 24 settings wired, dead ones removed; logging no longer declared; push capabilities gated per connection. It also let registry.pageSize through -- collision 15.
#74 -- exec flags accepted and ignored #75 Five flags now work for inline snippets, with a guard table that asserts an observable outcome. Local path only -- the remote path is #192.
--typecheck works (deno check) · upstream completion (/v1/complete forwards completion/complete, internal/api/ops.go:256) #66 · #61 Making the check the default is #79 on #100's decision (collision 1). Anything calling /v1/complete local-only is stale.
#40 artifacts / ExecOptions · #41 diagnostics, recipes, intent · #44 the plugin without the binary #57 · #58 · #53 Closed before the build-out began. The plugin reaches the daemon over the socket and spawns mcpx only as its last fallback.
#160-#170 duplicate testing issues this pass Closed earlier "until reconciled"; their remaining unique content was carried into the survivors (#132-#143), each listed in a comment.

In flight at the time of this revision (other architects, merging now): #76, #77, #102, #108, #116, #172, #178,
#179, #180, #183 and #153; decision records for collisions 2, 3 and 10. When they land, this section gains rows.

Ease vs impact

Ratings are the leaves' own footers, and each category tracker's table agrees with its leaves. Four quadrants.
Quick wins pay immediately and cost hours to days. Big bets are what the project is for and cost weeks.
Fill-ins are cheap and change nothing structural. Thankless is expensive work with a narrow beneficiary -- do it
when someone asks by name.

Quick wins -- do these first

Issue Ease Impact Why
#108 (in flight) S high One flag. --runtime node restricts the language it claims to enable.
#116 (in flight) S med-high diagnose.CallError is written, tested, and called by nothing.
#192 S (B) / M (C) med-high A remote exec accepts and drops most exec flags -- including --env and inline --export, whose wire fields already exist. #74's class on the path #75 did not cover.
#138 S-M high e2e still appends os.Environ() (e2e_test.go:52), so a developer's MCPX_* leaks in. The last precondition for t.Parallel.
#129's settings-effect guard M high Collision 15: a setting must be able to change behaviour, not merely be read. Before or with #172.
#193 S / M med /v1/events replay drops past 256 events with no gap, though reconnection is documented as lossless.
#102 (in flight) · #178 (in flight) · #179 (in flight) · #180 (in flight) · #183 (in flight) S each med / low-med The rest of #177's small promise/behaviour fixes.
#189 · #196 · #188 · #190 · #191 S · S · S · M · S high · high · med · med · low-med Found by the merging architects while this pass ran, all under #177: the plugin's DaemonClient.call sends field names /v1/call does not read (#189); PoolID hashes headers in map order (#188); a wrong-case cwd keys a second daemon (#190), and so does any cwd under $HOME, which lists the user config twice (#196, PR #197 open); a log line misnames the scope (#191). Likely fixed in those architects' PRs -- check before starting.
#88 S → M med Resolve the socket through the info file; owns MCPX_SOCKET precedence (collision 8). #182's stop --all already works this way.
#101 S (B) / M (C) med docs/runtimes.md -- still does not exist. Its probe suite can run in the existing CI job.
#143 M high First real CI iteration with a recorded baseline (at 05c78b2: test step 148 s, e2e 108.9 s, nix build 70 s).
#141 M med Formatters and linters in the matrix; the plugin's 21 bun test tests have never run in CI.
#117 S high Pick the site generator; the recommendation is already made. Everything in #90 waits on it.

Big bets -- the work the project is for

Issue Ease Impact Why
#175 L-XL high #100 M, #103 L, #104 L, #105 XL (slice 1 M), #106 M/L, #107 L, #187 M. "mcpx runs your code", currently one runtime deep.
#176 L-XL high #109 M, #110 L, #111 L, #113 L, #114 L. Where a model comes from, and what uses one.
#173 L-XL high #83 up to XL; #80 and #81 M/L. The plugin contract every future integration hangs off.
#97 XL high Integration tests for every feature across environments. Without it every other bet is unverifiable.
#93 L high One seed per run, a seed store, bug-shape generators -- the notes' "hack job of antithesis/tigerbeetle".
#89 / #98 XL high / med The book. The compendium is open-ended by design.
#158 L high Release workflow and artifacts. Gates the download link and install commands on the home page.
#177 M overall high Fourteen children, individually S-M; the value is in doing the set and guarding the frame afterwards.
#6 (the store) M-L med The durable event store. Its gap contract (S) is split out and comes first.

Fill-ins -- cheap, safe, do them when blocked on something else

Issue Ease Impact Note
#119 S med Subdomain + CNAME, after #118 creates the Pages site.
#149 S (gallery M) med-high The FAQ, in the notes' own voice.
#153 (in flight) M med Comparisons and the project's history; COMPARE is writing docs/compare/ now.
#126 S low now, med long-term Research only -- deterministic execution as an aspiration.
#131 S high A contributor test page agents load.
#150 M med Release markers and <details> section history.
#7 M med Launcher placeholders. Self-contained.
#5 S-M med paths.config -- currently dead on config, env and flag alike.
#78 S low-med Daemon state and cache correctness; none of its items was touched by #69/#70/#73.
#11 S low Renovate's dashboard. Outside the milestone; the bot maintains it.

Gating design objects -- small, and three issues each wait on them

Easy to misfile: by ease they look like fill-ins; by consequence they are phase-3 design. Each came out of a
collision nobody owned. Do them before their consumers.

Issue Ease Impact Waited on by Why it gates
#186 one near-miss matcher S med #109, #111, #7 Two implementations already exist and disagree; a third arrives the moment #109 or #111 starts.
#185 ClampedBy M med (high once a dial ships) #111, #112, #113 A daemon-set ceiling a caller may lower but not raise -- a settings capability, not a repair feature.
#187 one cache mechanism M med-high #103, #104, #107, #78 Cheap now, a migration after the first of the three ships its own cache. The prior art is already in the tree: #69/#70/#73 gave exec content-addressed workdirs, sized for scripts rather than node_modules trees or Nix closures.

Thankless -- real work, narrow beneficiary. Wait to be asked.

Issue Ease Impact Why it waits
#84 (C ABI, WASM halves) L each med overall, low until a caller names itself The Go package API half is not thankless; the ABI and WASM halves are.
#105 slice 2 (the Python runner) L high if wanted The notes do ask for it ("support python wherever and however typescript is used 1:1"), so it is not unwanted -- but slice 1 (a typed Python client, M) should prove demand before the runner. Slice 1 is a big-bet item, not thankless.
#136 (Windows tier) L low Zero //go:build windows files. A port, not a matrix leg -- recommendation 3.
#136 (flatpak tier) M very low Drop, do not schedule -- recommendation 2.
#156 (beyond copy-as-command) M (XL hosted) med #156 recommends a copy-as-command example (S) and an in-browser simulation (M), never a hosted daemon; WASM is not the plan.
#152 L med Migrating the existing design docs into the compendium.
#82 L med-high, or near zero High if plugins land, near zero without them. Strictly after #80.
#86 (embedded UI slice) M-L med Serving a directory is S. An embedded frontend is where a second toolchain sneaks in.

Proposed order

Seven phases. The reasoning is in each header; hard dependencies are in the graph below. In flight means another
architect is merging it now -- do not start it, check it.

Phase 0 -- the one-line wins

#135's cache line (done, #182) · #108 (in flight) · #116 (in flight) · #192 (B) · #186

The cache line and #52 are done. What remains here costs hours: #108 and #116 are already being merged; #192's B half
is filling two execsvc.Options fields the CLI never sets; #186 unifies two disagreeing matchers before a third is
written.

Phase 1 -- make the suite trustworthy before making it bigger

#138 → #143 → #49 → #141, with #127 + #131 (the agent test policy) alongside

#52 no longer blocks anything. The remaining isolation hole is #138 -- e2e appends the caller's whole environment --
and it is also the last precondition for t.Parallel in #139. Then #143 records a baseline, because #139 shards by
measured time and #140 budgets against it. The baseline at 05c78b2 (run 36693030957): setup 22 s, test step 148 s of
which internal/e2e is 108.9 s across 209 tests, nix build 70 s of which checkPhase is 18.5 s.

Phase 2 -- close the promise/behaviour class while it is small

#129's settings-effect guard (before or with #172) → #177's children · #128 · the rest of #129

Most of #177's fourteen children are small and several are in flight (#102, #108, #116, #172, #178, #179, #180,
#183). The one ordering constraint that matters: #129's guard that a setting can change behaviour must land before
or with #172, which is about to declare 44 more MCPX_* variables into a registry whose guard only proves a
setting is read (collision 15). #192 and #193 are this pass's additions and are not in flight.

Phase 3 -- the design objects other issues extend

#100 · #103 · #187 · #110 (decide) · #83 slice 1 → #83 slice 2 → #80 · #76 (in flight) · #6's gap contract · #5 · #185

Each of these is extended by several other issues, so getting it wrong is expensive and getting it late is worse.

Phase 4 -- release and packaging

#134 → #136 → #178 (in flight) → #158

A Containerfile exists now, but nothing builds or tests it (#134), and Renovate is already bumping it to Go 1.27 while
go.mod says 1.26.7 (#184) -- a drift nothing catches. #136 is now a policy decision (which shipped artifacts are
static; recommended: add a Linux mcpx-static output, keep the default nix package as is -- but open PR #194
flips the default instead, which would settle it as option A). The version is hard-coded
in four places (package.nix:19, :61, cmd/mcpx/main.go:18, Containerfile:40) and the man page stamps
time.Now() (#178). #158 blocks #155's download link and install commands; #157 can ship before it with an honest
status column.

Phase 5 -- the site, then the pages

#117 → #118 → #119 · #144 → #145 → #146 → #147 #148 #149 · #157 · #120 · #155 → #156

Put #144/#145 before the manual pages so they are generated from the binary rather than hand-copied (#96, and the
lesson of #159). #119 needs the Pages site #118 creates, so it follows rather than runs alongside.

Phase 6 -- the big bets, in dependency order

Every child in #176 has a deterministic lower half that ships without a model and a model-backed upper half that does
not, and in every case the deterministic half carries more value. Do all the lower halves first.

Phase 7 -- the compendium and the long tail

#150 · #152 → #151 · #153 (in flight) · #154 · #126 · #84's ABI/WASM halves · #105 slice 2

Open-ended by design. #150 and #152 come first (#98's own order); #151 needs #150 and #158.

Dependency graph

Hard dependencies only -- "B cannot be done correctly until A is". Done nodes are grey.

graph TD
  subgraph DONE["Done"]
    I52["#52 leaked daemons<br/>fixed in #182"]
    CACHE["#135 cache line<br/>fixed in #182"]
    CF["Containerfile<br/>#182"]
    SET["settings guard<br/>#171"]
  end

  subgraph P0["Phase 0 · one-line wins"]
    I108["#108 --runtime node<br/>(in flight)"]
    I116["#116 wire CallError<br/>(in flight)"]
    I192["#192 remote exec drops flags"]
    I186["#186 one matcher"]
  end

  subgraph P1["Phase 1 · a trustworthy suite"]
    I138["#138 e2e env allowlist"]
    I143["#143 first CI + baseline"]
    I139["#139 shard by measured time"]
    I140["#140 time budget"]
    I49["#49 build every package"]
    I141["#141 linters + formatters"]
  end

  subgraph P2["Phase 2 · guard the frame"]
    T177["#177 promise vs behaviour"]
    I172["#172 44 undeclared MCPX_*<br/>(in flight)"]
    I129["#129 settings-effect guard"]
    I193["#193 events replay loss"]
  end

  subgraph P3["Phase 3 · shared design objects"]
    I100["#100 runtime + script.check"]
    I79["#79 typecheck default"]
    I103["#103 dependency chain"]
    I187["#187 one cache mechanism"]
    I110["#110 provider layer"]
    I83["#83 anything as a tool source"]
    I80["#80 plugin contract"]
    I76["#76 CLI for /v1-only ops<br/>(in flight)"]
    I6G["#6 gap contract"]
    I5["#5 paths.config"]
    I185["#185 ClampedBy"]
  end

  subgraph P4["Phase 4 · release"]
    I134["#134 container in CI"]
    I136["#136 static-artifact policy"]
    I178["#178 man/completions/version<br/>(in flight)"]
    I158["#158 release.yaml + artifacts"]
  end

  subgraph P5["Phase 5 · the site"]
    I117["#117 pick generator"]
    I118["#118 build + deploy"]
    I119["#119 subdomain"]
    I120["#120 agent markdown"]
    I144["#144 reference pages"]
    I145["#145 emitters + drift check"]
    I155["#155 home page"]
    I159["#159 docs contradict code"]
    I150["#150 release markers"]
    I151["#151 history renderer"]
  end

  subgraph P6["Phase 6 · big bets"]
    I104["#104 import graph"]
    I106["#106 shebangs + resolution"]
    I105["#105 Python"]
    I107["#107 flake refs"]
    I109["#109 better search"]
    I111["#111 check / refuse / repair"]
    I112["#112 exec lifecycle hooks"]
    I113["#113 admin by intent"]
    I114["#114 tool views"]
    I81["#81 hooks over the bus"]
    I82["#82 privileged plugin surface"]
    I84["#84 embedding mcpx"]
    I85["#85 ssh"]
    I86["#86 web frontend"]
    I88["#88 socket resolution"]
    I97["#97 integration tests"]
    I93["#93 fuzzing"]
  end

  CACHE --> I143
  I138 --> I139
  I143 --> I139
  I139 --> I140
  I49 --> I141

  I116 --> I111
  I108 --> I100
  SET --> I129
  I129 --> I172
  I172 --> T177
  I192 --> T177
  I193 --> T177
  T177 --> I97

  I100 --> I79
  I100 --> I104
  I103 --> I104
  I187 --> I104
  I187 --> I107
  I5 --> I103
  I104 --> I106
  I106 --> I105
  I106 --> I107

  I186 --> I109
  I186 --> I111
  I185 --> I111
  I185 --> I112
  I185 --> I113
  I110 --> I111
  I110 --> I112
  I110 --> I113
  I110 --> I114
  I109 --> I111
  I76 --> I113
  I6G --> I81
  I6G --> I193
  I83 --> I80
  I83 --> I114
  I80 --> I82
  I80 --> I84

  I88 --> I85
  I88 --> I86

  CF --> I134
  I134 --> I158
  I136 --> I158
  I178 --> I158
  I158 --> I155
  I158 --> I151
  I150 --> I151

  I117 --> I118
  I118 --> I119
  I117 --> I120
  I117 --> I155
  I159 --> I144
  I144 --> I145

  I139 --> I93

  classDef done fill:#555,stroke:#888,color:#ddd
  classDef quick fill:#1f6f3f,stroke:#0b3,color:#fff
  classDef bet fill:#5a2d82,stroke:#93c,color:#fff
  class I52,CACHE,CF,SET done
  class I108,I116,I192,I186,I138,I88 quick
  class I93,I97,I110,I83,I104,I105,I113,I114 bet
Loading

Removed from the previous revision because they were not hard dependencies: #52 → #139 and #52 → #97 (done),
#78 → #88 (#88 decides the MCPX_SOCKET question itself, collision 8), #88 → #87 (independent per #174),
#6 → #81 (only the gap contract is needed), #145 → #159 (a cycle with #159 → #144 → #145; #159's findings feed
#144, and #145's drift check then keeps them fixed), and #103 → #107 (#107 sits on #106's interpreter seam).

The evidence behind the dependencies asserted here

Checked by hand on 8001f23 when this tracker was written and re-checked on 05c78b2 in the 2026-09-30
issues pass. Each item names the leaf that owns it, where the detail lives.

Conflicts between themes that no single tracker can see

These surfaced only when the themes were put side by side. Each is a real collision between two
issues written by people who could not see each other's work. When this tracker was written none
had an owner; each now has one (2026-09-30 issues pass), and every affected issue carries a
comment naming it. The owner decides; the other issues adopt the decision rather than making their
own.

# Collision Issues What happens if nobody decides Owner
1 Two breaking changes to one shipped setting in one cycle. #100 renames script.typecheck → script.check; #79 flips its default off → on. It is documented in docs/configuration.md and still Default: "off" at internal/settings/registry.go:244. #100, #79 Users who set it get broken twice, or whoever lands second silently reverts the first. Decide alias-vs-replace once, in #100, before #79. #100 -- recommends an alias with a value map (an unknown config key only warns, settings/file.go:32-58); #79's default flip lands on it. daemon.inline (#79) needs the same registry capability
2 Four hook vocabularies. script.* (shipped), #81's hook-point table, #82's runtime hook registration, and #112's prePrompt/postPrompt/onError list. #81, #82, #112, shipped Reconciling them later is a breaking config change. #112 is in a different theme from #81/#82, so nobody currently owns the overlap. #81, via a SURFACES decision record in docs/decisions/ (in flight); #82 and #112 adopt it. Input: shipped script.* has five phases and its onError rethrows, while #112's may replace the result
3 Three autonomy dials, independently invented. #111's repair.level, #112's hook effect, #113's prompt.mode: plan. #111, #112, #113 A user learns three vocabularies for one concept. Settle it in #111, which is the earliest of the three. #111, via a SURFACES decision record in docs/decisions/ (in flight); #112 and #113 adopt it
4 Namespacing and collision rules designed twice. #83's tool-source interface and #114's cross-server namespaces, script-backed tools and generated declarations are substantially the same problem. #83, #114 Two namespace schemes that must later be merged. #83 is in #173, #114 is in #176. #83 -- defines namespace and collision rules; #114 builds on them
5 ClampedBy has no owner. #111 proposes a settings-registry feature — a daemon sets a ceiling, a caller may lower but not raise — and #112 and #113 both need it. It exists only as a paragraph inside #111. #111, #112, #113, #172 Implemented three ways by whoever reaches it first. It is an internal/settings capability, not a repair feature. #185 (new design issue under #176)
6 The edit-distance matcher has no owner. #109's typo tolerance over tool names and #111's near-miss detection on a failed call are the same algorithm over the same corpus. Both mention the other; neither claims it. #109, #111 Written twice and diverges, so search and diagnostics disagree about what "close" means. #186 (new design issue under #176) -- two implementations already exist and disagree. The notes' own example (search → query) is not a typo (distance 5), so argument-shape fit stays with #111
7 The exec Frame ordering contract is extended by two issues that do not know about each other's placement rules. #111 adds a call frame; #112 adds a hook frame with explicit before/after-result placement. docs/exec.md states the order as a contract. #111, #112 A documented wire contract changes twice with no one reconciling it. #111 -- states the rule for adding a frame kind; #112 follows it
8 #88 cannot be finished while #78 is open. MCPX_SOCKET overrides both the computed path and the info file, so "the record is authoritative" is not true until #78 decides how. #88, #78 #88 ships a rule with a hole in it, and #85/#86 build on the hole. #88 -- decides MCPX_SOCKET vs info-file precedence; #78 drops it
9 Three surfaces, one lifetime question. A browser tab vs daemon.idleExit (#86), leftover ssh ControlMaster processes (#85), and leaked e2e daemons (#52) are the same class. #86 says "decide deliberately" about its own case. #85, #86, #52 Decided three times, three ways. #87 -- activity on any surface renews the idle deadline; #85/#86 apply it. The e2e case is closed (#182)
10 Nobody owns the declared-vs-enforced capability boundary. #82 says capabilities should be declarable now and enforceable later; every other child defers security to this tracker. #82, all The deferral has nowhere to land. Noted here so it is at least visible; out of scope for now. #82, via a SURFACES decision record in docs/decisions/ (in flight). Security still deferred
11 auto hides all Node breakage from this repository. package.nix suffixes deno, bun and node onto PATH, so on any Nix install script.runtime: auto always resolves to Deno. Nobody testing through the flake will ever see what #100 and #108 describe. #100, #108, #49 The bugs stay invisible until a user without Deno installs it. Needs a pinned-runtime CI matrix. #100 -- partly outdated: e2e already pins each runtime explicitly; what remains is auto itself and non-erasable TS under node. The no-Deno CI leg is #134's e2e-no-deno row
12 Three new content-addressed caches. #103, #104 and #107 each introduce one, sized for node_modules trees and Nix closures — orders of magnitude larger than what pruneWorkDirs/defaults.ExecWorkDirs was sized for. #103, #104, #107, #78 #78 gets a fourth instance of the same problem. One cache design across the three. #187 (new design issue under #175)
13 events.history already answers #81's open question, and changes its design. The default is 1024 (internal/defaults/defaults.json:52, wired at internal/daemon/server.go:165). A saturated hook pool is therefore gapped, not merely slow, which the seq-watermark design has to handle. #81, #6 #81 designs against an assumption that is already false. #6 -- a gap {since, latest} contract (S) split out from the store; #81 and #193 consume it
14 Line references in the leaves have drifted past 8001f23. #88 cites maxSocketPath at paths.go:78 (now :96); #80 cites serve.go:322-336 for extras (WithExtras is now serve.go:346); #159 cites Commands() at manual.go:12-17 (now :33) and "~130 per-command flags" (the previous revision said this measures 118; it does not -- 118 typed flags plus 12 fs.Var, so 130 is right). #80, #88, #159, #172 Cosmetic, but a reader following them lands in the wrong place. resolved, not assigned -- every leaf was re-cited against 05c78b2 in the 2026-09-30 issues pass, including the three named here (#88 paths.go:96, #80 serve.go:328-346, #159 manual.go:33), and #159 corrected this row's own flag count: 130, not 118 -- 118 typed fs.String/Bool/Int/Duration plus 12 fs.Var. Standing rule for the next drift: cite a commit beside the line number
15 The newest guard test has a hole, and it let a defect through. consumed_test.go proves a setting is read; it cannot prove that reading it can change behaviour. registry.pageSize is consulted only inside if limit <= 0 (internal/registry/registry.go:154-156), so no ordinary caller reaches it — and it passed #171's sweep anyway. #179, #129, #172 The same hole may hide among the other 148 settings, and #172 is about to declare 44 more into the registry that would inherit it. Check it before #172 lands, not after. #129 -- a setting must be able to change an observable outcome; apply before/with #172
16 #159's item 13 is wrong, and acting on it would break the generated client. It claims MCPX_SESSION is misnamed and implies MCPX_CALL. MCPX_SESSION is set at commands.go:672, execsvc.go:575 and internal/daemon/consumer.go:536, read by the generated TypeScript client at internal/codegen/emit.go:253, and asserted in internal/e2e/runtime_test.go:43,65. MCPX_CALL exists nowhere. #159, #180 A "cleanup" rename breaks every generated client. #180 carried the correction; #159 now carries it too. #159 -- corrected in the 2026-09-30 issues pass: item 13 struck with the reason. What remains is a doc line: docs/opencode-plugin.md:406 says the plugin sets MCPX_SESSION/MCPX_CALL; it sets MCPX_SESSION_ID/MCPX_CALL_ID
17 Two counts of the same thing that have never been reconciled. #172 says 44 undeclared MCPX_* of 64 referenced; #159 says "about 49". The two used different allowlists. #172, #159, #180 Whoever implements #172 will pick one and quietly contradict the other. Define the allowlist once. #172 -- defines the allowlist once. Resolved on #159's side: it now cites #172's 44
18 docs/parity.md cannot distinguish its two kinds of gap. 33 rows against 60 operations — 27 absent — while its own ## Known gaps section describes gaps within the 33 documented ones. #159, #144, #145, #180 A reader believes the missing 27 are complete-and-undocumented rather than undocumented-and-unknown. #145's drift check should fail on an absent row, not only a wrong one. #145 -- decided in its step 7: one generated row per op, an absent row fails naming the op, a known gap is an explicit — with a reason

Standing recommendations — where I would pick differently from the notes

The notes are the source of truth for what to build. These six are places where I would build it
differently. Every one is quoted verbatim in the leaf that owns it and argued there too; this
section exists so the disagreements are visible from the root rather than buried five issues deep.

1. sudo $(curl <short> | sh) is not a system-wide install — it is a root code-execution primitive

The notes propose, for the home page:

  • per-user curl <short> | sh [copy-button]
    • ~system-wide sudo $(curl <short> | sh) [copy-button]

$(...) is command substitution. The shell runs curl <short> | sh first, as the unprivileged
user — so the installer never sees root and either fails or installs per-user anyway. Then the
shell takes that command's stdout, word-splits it, and hands the result to sudo as a command
line. If the script prints Installed mcpx to ~/.local/bin, sudo tries to execute a program
called Installed. If anything can influence what the script prints — a mirror, a proxy, a
compromised CDN edge, a stray set -x — it controls a root command line directly. This is strictly
worse than the thing it is trying to be.

Use curl -fsSL <short> | sudo sh. Better still, do what rustup and Deno do: one unprivileged
curl | sh, and let the script ask for elevation only for the step that needs it, so the user can
read the prompt and see what is being elevated. Owned by #155 (copy buttons) and #157 (install
page); the script itself is #158.

2. Flatpak is a poor fit and should be dropped from the wishlist, not merely deprioritised

The notes list it twice:

  • bash/nix/agent-prompt
    • (pwsh/rpm/flatpack/pkg/docker/justThePlugin)
  • alpine-slim/FROM scratch/distroless/flatpak

Flatpak packages sandboxed desktop applications; host access is mediated by portals. mcpx is a CLI
plus a background daemon that must (a) bind a unix socket at a host path that other processes —
opencode, agents, mcpx itself — open by name, (b) spawn deno/bun/node subprocesses, (c) read
the user's whole config chain, and (d) execute arbitrary user scripts against arbitrary paths.
Supporting that under Flatpak means --filesystem=host --share=network --device=all --talk-name=*,
at which point the sandbox is off and what remains is a tarball with extra indirection and a worse
$PATH. Flathub is also not a distribution channel for CLI-only software.

The channels that actually fit are a tarball plus an install script, Nix (already works),
Homebrew, and an OCI image. Owned by #136 and #158. I would put the saved effort into the OCI
image, which the notes also ask for. A first Containerfile landed in #182 (bun, debian-slim,
413 MB); what it still lacks is a CI job, tests, and a release channel (#134, #158).

3. Windows is a port, not a matrix leg

  • windows-11

There are zero //go:build windows files and zero _windows.go files in the tree. The daemon
binds unix sockets (internal/daemon/server.go, internal/cli/client.go,
internal/daemon/routes_resolve.go), resolves paths through an XDG chain, detaches itself to
outlive its parent with --idle-exit, and dispatches shebangs. Windows has AF_UNIX, but the
detachment model, the service model, the path chain, signal handling and shebang execution each need
a deliberate implementation. That is a port with a design issue in front of it; a windows-latest
line in runs-on would fail on the first test and tell you nothing you do not already know.

Tier it as "port, unscheduled". If anyone wants it, the first deliverable is a design issue
naming the five boundaries and choosing named pipes vs AF_UNIX. Owned by #136.

4. Alphabetical sharding is the wrong partition once timings exist — but the timings come first

The notes anticipate this themselves, which makes it a refinement rather than a contradiction:

at some point start splitting logical units by like, e.g. maybe a-f/g-s/t-z, balance number of letters by time.

Letter ranges are an arbitrary partition with no relationship to runtime, and the only way to
rebalance one is to move a boundary — which moves many tests at once and usually overshoots.
go test -json emits an Elapsed per test for free. With that, greedy bin-packing (LPT: sort
descending, assign each test to the currently-shortest shard) is the standard makespan
approximation and is provably within 4/3 − 1/(3m) of optimal, versus no bound at all for letters.

Measure first, shard second, and never shard alphabetically once you have numbers. The notes'
own warning about the pathological case is exactly right and is the one thing LPT cannot fix:

consider if theres lengthy tests which are '1' test but re-exec N times 'in parallel': they will only run 1-3 at a time and so 30 cases could take up to 10 tests worth of time even in parallel and may need to be examined.

A test larger than the target shard size is indivisible to any scheduler. That one has to be split
at the source. Owned by #139, with #143 producing the measurements.

5. Sampling is deprecated, which inverts what docs/consumer.md recommends

MCP revision 2026-07-28 deprecates Sampling, Roots and Logging under SEP-2577. The spec names
the migration for sampling explicitly: integrate directly with LLM provider APIs. Deprecation is
annotation-only with a twelve-month floor, so nothing breaks before 2027-07-28 — but "new
implementations SHOULD NOT adopt it" is the spec's own wording.

mcpx already speaks 2026-07-28 and already implements the MRTR inputRequired round trip that
replaced the held-open stream. But docs/consumer.md:156-170 still frames sampling as the path for
prompt.sample, and mcpx declares roots to every upstream server (docs/protocol.md:271; code at
internal/mcpclient/modern.go:52) — deprecated by the same SEP. It also declares sampling whenever an
elicitation handler is installed (modern.go:54-56), which the daemon always installs, so in practice
every upstream server is told it may sample.

A configured provider is no longer the ambitious option; it is the spec's own suggested
migration. That inverts the framing in docs/consumer.md and makes #110 a prerequisite rather than
an enhancement -- in the sense of decide now, build later: #176 builds it fifth. The two consequences
this section said nobody owned now have one: #110 carries the roots and sampling declarations and the
docs/consumer.md sentence that must change with its decision.

6. Prefer settings over endpoints — restated, because it is the rule most easily lost at scale

This held. The leaves propose settings and conventions where the notes proposed endpoints: #87
replaces a renew-endpoint-per-resource with touch-on-read; #112 replaces four prompt endpoints with
one declared hook list; #86 adds http.ui settings rather than a second build system. The place it
is most at risk now is #113, where "administration by intent" could easily become a dozen
/v1/admin/* routes. It should not: the ops table already generates routes, MCP tools and OpenAPI
from one declaration, so the correct move is to declare more operations, not to hand-write more
endpoints — and internal/api/parity_test.go already enforces that.

Original notes

This paragraph closes the user's first notes file. It is an instruction rather than a feature, which
is why every writer obeyed it and none of them quoted it; a coverage audit across all 113 issues in
this repository found it in none of them. It belongs here, at the root, because it governs the whole
backlog rather than any one issue:

in some places i used new api endpoints and names but dont take anything i said as authoritative direction, its the idea or vibe that matters, the concept. when possible don't add new endpoints add settings or options, flags, conventions or other best practices way to handle.

The user's full original notes, verbatim — both files, concatenated, nothing removed. (click to expand)

Two files. Nothing below is edited, corrected, reordered or summarised. Typos are the user's.
Every non-empty line here is quoted verbatim in at least one open leaf issue, except the closing
paragraph, which lives here at the root. Re-checked by script against the live issue bodies at the end
of the 2026-09-30 issues pass: 196 of 197 lines are quoted in at least one open leaf; the 197th is the
closing paragraph quoted above.

Source 1 of 2 — runtimes, extensibility, surfaces, the AI layer

- how do i set the js runtime?
  - you had mentioned node alongside bun etc, would a user run javascript there? typescript would fall over? 
  - what is or can be automatically stitched together or compiled to js or doesnt need to can run ts direct?
  - if node would fall over, could existing ts be compiled for a js project?
  - is there a way to support .dt js type files? at least for validation etc?
  - handle validate/import/compile automatically when possible then provide config to disable/skip/run-but-keep-going-on-error/etc.
- document compare the options and features
- how to config npm
  - from host default
  - from cli config
  - from cli config dir
  - from pwd dir nodepackages
  - from /v1 /mcp (and cli/plugin)
    - command to pass list of packages, package.json(c) (package.lock supported too)
  - baked into binary
- can i make a go module accessible c
- plugins
  - go plugin
  - binary plugin
  - typescript/python plugin
  - script/shebangable plugin
  - config can set hooks for non-go/typescript(/python)
  - config can set hooks to call any command,js/ts/py module
  - remote socket/v1/mcp/otherPlugin plugin
  - go/ts(/py) can directly interact with app set own hooks, get/set vars, trigger any external command internally which can be triggered outside the app or in a script, call public and private functions of app, fork configure socket shutdown and independently interact (maybe this mode also supports still get/set vars transport types rpc anything they could do inside.
- support python wherever and however typescript is used 1:1
- can exec call bash across the modes?
  - nearly just allow any shebang
    - drop the user in <user_config>||<config>||pwd
    - if not shebang or --shell||--bash||--shell python3||--#!/usr/bin/python
    - then configured typescript
  -  ./mcpx -exec 
- support adding bash/js/ts/py scripts as mcp
- ssh rpc, ssh server, ssh tui
- web frontend
- support embedding/config/dynamic-add "mcp" for any plugin above
- support embedding/config/dynamic-add mcp endpoints, connect to self over sockets?
- support embedding/config/dynamic-add any binary as mcp
- binary mcp
- better natural language processing search
- mcp-owned opencode api support
  - support multiple providers/models
  - name priority sets of models as an 'agent'
  - ? just embed opencode and call it? is there a golang or rust opencode? 
  - proxy
  - respond to elicit/prompt
  - receive errors check io and elicit/prompt caller, or fix-retry, clean up return what worked with explanation of what happened, pass-through
  - install any language/tool/framework/library, clone whatever repo.
  - check inputs, reject any request with/without reason, prompt 'hey are you sure? you did this and that maybe doesnt do what you think', 'hey i mean this probably cant work because y', or it can look at a script and say 'oh, they used search instead of query, query is only thing that makes sense here and they used the args for query, i'll rewrite the script and run that instead (or offer alternative ask them), user can just tell it what to do and then mcpx does the ai part/script-selection, or write a lazy psuedocode script mixing 4 languages and calling packages from different ecosystems and it puts together best it can with some guidance/instruction/accuracy/precision/strictness either decline, propose script ask for approval, emit scriptfile and return fileid, decide to run first part first thats safer, implement a dry-run and try that, disregard users attempt and exec/make/suggest what they actually want.
    - need ways for server and client both to control their section maybe need auth
  - prompt-based served endpoints (tell mcpx to do a thing it tries its best, tell it to install/remove/reconfigure itself, add/remove/configure mcp, administrate, restart mcp servers, force-detach, kill sessions, resume dead sessions, get config, exec/runwhatever. (same interface for this and clients? plugins?) 
  - accept prompt/prePrompt/postPrompt/onErrorPrompt/onSuccessPrompt
    - the script interface just runs the scripts, but you can provide a prePrompt saying hey i added a bunch of dependencies please make sure they exist where the job runs, postPrompt to clean up the results and transform, either prompt/pre/post could say to fix error thing but onError gets provided above or below the error and is first seen with the error if theres an error. prompts can use templatevars to put content where they want it or for prompt overall to be stopped/resumed maybe.
  - generate OpenAPI.fromSpec for a binary or script or any executable/whatever and add it as an mcp, save the openapi json for reuse by hash or similarity
  - generate new mcp commands out of existing 1 or more
  - generate new mcp commands that trigger its own prompts/scripts/binaries
  - generate new x_commands for an mcp and add them into the given mcp
    - doesn't have to just be merging transforming filtering limiting existing
    - can extract the creds pull the api and add endpoints from sdk missing in mcp using the sdk descriptions 
  - add the dropboxMcp, googleDriveMcp, outlookMcp, tailscaleMcp
  - please make an alias for the tailscaleMcp except it should not require auth it should accept the creds i already used to connect to it and the only skill it should provide is listTailnet and listHostnames
  - accept user feedback, requests, routinely implement features/interfaces that are good idea. "you should add this mcp it's free." "this mcp is very good you should consider hosting it locally because the public one is slow and limited" 
- elicit/prompt/session/attachment/mcp/etc renew ttl
- any exec local or remote should allow file scripts, server looks where it finds scripts and tries to find, same as local.
- accept a flake url#path anywhere a binary/script/remote/api/etc can be used
- accept a flake url as an alternative exec env (devshell/shell.nix in default pwd or tempdir or ad-hoc flake that isfully isolated, path executed before script, script executed inside 
- reverse-shell/shell/ssh/tui
- web server
- non-ai auto-import dynamic if a script imports something that isnt avaialble
  - because of typescript and esm the entire import tree can be determined without executing anythign right?
  - if i import a file in another dir that has its own package.json/lock can it auto-import, prepare dependencies to be available whereever needed
- the following is a fixed thing but can that redirect path thing be deterministic so it can be safely followed? or no because reasons? does mac have a mac file length?
  - > A leaked daemon is one the e2e suite started and never stopped. Each test builds a temp config, runs a command, and the command auto-starts a daemon to serve it. The daemon is deliberately detached so it outlives the command, with --idle-exit 4h. Cleanup calls mcpx stop, but when that can't reach the daemon — a different config fingerprint, a socket relocated because the temp path was too long, an interrupted run — the daemon stays up for four hours with a fakemcp child. Fifteen suite runs left 70.

in some places i used new api endpoints and names but dont take anything i said as authoritative direction, its the idea or vibe that matters, the concept. when possible don't add new endpoints add settings or options, flags, conventions or other best practices way to handle.

Source 2 of 2 — testing and documentation

make an issue to design a comprehensive docs/testing strategy:
- testing
  - importantly, as we add more testing agents should not run every single test basically ever. below documents a rough idea of a ci job design/policy, the main priority is being short as possible.
  - agents should make at least 1 simple, new test for every bug observed from any source, when cheap to do so-- aggresively test many permutations. 
    - you can absolutely rely on fuzzing anywhere you can fit it and you should whenever you can-- but you _must_ use a single seed per-run to generate all inputs. (this could eventually be discussed with careful consideration.) it should be appended into a test tracking structured file in the repo and it can be committed. ideally main branch commit's seed or pr merge seed should make it back into file eventually. to prevent churn, maybe ci appends the seed into a gha var (race/overwrite risk?), or attached as artifact to each workflow in init job before tests begin-- a collector job can scoop them up sometime later. once a day/week/on-release/every-100-commits. im thinking touch tests/seeds/<seed> or uv has a seed generate job. anyways ci it should end up in that dir, then as an artifact if gha and main branch, then passed into the test matrix. if uv test without arg- warn, generate and write it yourself pass it to all tests, if some other testing method there should not be a static seed, throw for empty or setup should make the seed. avoid changing how seed generates data. im not sure if a convenient uuid with time, v7?, is valid, but as long as its enough entropy whatever works. either put nothing in their or compact json, consider seeds/v1/id/<first 2 char>/<seed><--symlink: seeds/yyyy/mm/dd/<seed> avoiding conflicts is important.
      - think a hack job of antithesis/tigerbeetle. this is the primary testing method is throw insane amount of variations. if something is found outside this system and a test that could have had missed it, make a different generator that uses the same seed and makes an infinite amount of things matching the offensive shape.
        - make a simple issue for reviewing all tests, setting up framework and policies for the fuzz.
        - we aren't shooting for deterministic execution to start, maybe we should but no. consider it a longterm design aspiration to retrofit or for rewrite in rust (not a plan at all, but could see it). separate simple issue for considering both those things.
  - a general goal is to ensure all features have one or more integration tests
    - the mcp servers can be specialized mocks but the app entrypoint or binary is used and config is passed in or config path set to appropriate test
    - for both binary && app entrypoint (consider binary a superset)
      - all tests should pass for nix flake & container
        - all local also but may need impractical setup
          - very few shouldn't work if user has own real daemon running
        - all non-cli should pass for remote
        - ideally would like if worked:
          - alpine-slim/FROM scratch/distroless/flatpak
          - fedora-kde,silverblue/kinoite,ubuntu
          - windows-11
        - a specific subset should completely work with all real software
          - these should be found/labeled whenever possible
          - the supported mcp version is the one in the flake/containerfile 
        - basically everything should work because static binary
          - non-vanilla may need extra config
          - installers make assumptions and require permissions
  - make a comprehensive github action ci.yaml workflow (or test.yaml) that is as fast as possible,
    - splitting sets of tests into as small groups as practical, eg split out unit/integration tests into 2 jobs, whichever one takes longer: shard it into 4 logical groups (or however many) based on an appropriate category, then find the longest job at that point and repeat (you dont want to iterate on this forever, at some point start splitting logical units by like, e.g. maybe a-f/g-s/t-z, balance number of letters by time.
    - continue until the jobs can't get much faster considering setup/teardown and then set a ci testing budget which is a hardcoded default input. after the test matrix have a time budget job when subtracts github workflow request time from now. (this catches if the jobs are impacted by matrix size, could lessen by taking initial job end or matrix start time.)
    - repeat this process whenever testing exceeds some time budget. make setup faster, rebalance alpha splits, split groups of tests on the longest shard. maybe flag that never tears down because just killing the box after. anything downloaded should be cached, shallow clone a partial path to mcpx dir, if there's unexplainable job start delays, try to keep all job times balanced, 10 ultrafast ones can give you quick signals but may put pressure on runner infra and cause the longest jobs to last a little longer. all that matters is how long the longest jobs take. job runners have 2 or 4 cores, consider if theres lengthy tests which are '1' test but re-exec N times 'in parallel': they will only run 1-3 at a time and so 30 cases _could_ take up to 10 tests worth of time even in parallel and may need to be examined. we're using go so im not too worried about time budget but its best to get this early. main focus is strong tests as each step of the lifecycle.
    - all formatters and linters in test matrix, formatters in check mode, linters set to warning or more than minimal.
    - automatically runs for every commit to main and on commit/open/undraft to a non-draft pr
  - separately, format.yaml which auto-commits to main when format has changes and successfully completes all formatters, receives a green test workflow
- documentation
  - make a book using whatever is the most common and simple modern choice
    - that thing all the rust/k8s people use is fine
    - github static setup. separately, assign a subdomain
    - specialized agent markdown all pages
      - home page has install prompt built into the bot version
    - 3 main things, not book sections jsut like levels of detail-
      - the 30 seconds look at home page click the overview page, click the quick start page, ctrl+w should be simple enough that even this person skimming while doing 3 different things will accidentally learn
        - why you would install it
          - code mode
            - makes shareable, reusable scripts
          - reclaim context, use less tokens
            - smarter, cheaper
          - tame mcp
            - one mcp config
            - share endpoint with your tailnet
            - corral your scripts, apis, and binaries
        - how to install it
          - picture architecturally what it looks like
          - aware of install
            - bash/nix/agent-prompt
              - (pwsh/rpm/flatpack/pkg/docker/justThePlugin)
            - install as
              - just exec the binary
              - per-user|per-host
              - optional:
                - local host
                - system service
                - persistent daemon
          - home page has
            - short flex video
            - simple intro
              - short 1-4 sentence paragraph
              - surrounded by small title/small here-blocks/bigger word lines
              - code block example
                - static syntax-highlighted typescript
                - exec real editable example click button remote
                - wasm, local mcp, daemon/cli-client
            - download link
            - per-user `curl <short> | sh` [copy-button]
              - ~system-wide `sudo $(curl <short> | sh)` [copy-button]
            - <`subitem[rand(this.len)]`> [copy-button]
              - `hey please one-shot setup mcpx right now`
              - `hey install this mcpx thing and comment out all my mcp config`
              - `replace mcp with mcpx codemode`
              - `guided install mcpx now plz`
            - quick start
            - now what
      - the 'ok i just installed this thing what even is it' layer
        - basically a more normal set of docs
        - new person might assume this is all there is and wont be upset
        - a page or section in a page for
          - common config
          - server config
          - client config
          - env vars
          - client modes
          - transport options
          - server modes
          - abstract interfaces
          - client interfaces
          - cli
          - cli arguments
          - cli commands
          - mcp
          - mcp sdk
          - mcp compatibility
          - binary
          - script
          - /v1
          - /v1 sdk
          - plugins
          - plugin compatibility
          - plugin interface & config
          - opencode v1 plugin
          - opencode v2 plugin
          - vibeMcp
          - "so why'd you get rid of all the mcp and then make one, do you like mcp or not"
          - "i mean, opencodemode is right there"
          - "is it safe?", no.
          - "but why would you.."
          - "but can i get some examples?"
      - the compendium
        - basically everything that is built can be described here in as much detail as you want. you don't need to hold back it's an encyclopedia
        - new sections marked with release version during release.yaml?
          - edits start a 'history' openable that is just a sideways triangle out of the way, basically hierarchical updates, md para new version/date->bubbles up through h5 h3 h2 root document version history
        - you dont have to just put strict mcpx things here
          - document mcp servers, resources, indexes, urls, projects
          - compare with lootbin/opencodev2/cf-codemode/etc
          - history - lootbin abandoned (me), i asked to look into a replacement and came back to a built binary, i mentioned hey, did you notice opencodev2 has it built in and i'm already using opencodev1? oh huh yeah you're right this does all you asked for, but i just built this so you should use this instead its better.
          - any research or incidental findings into ai, llm, harnesses, plugins, token providers, cloudflare, the typescript ecosystem, SSE, sockets/rpc/websockets/tcp/mcp/openapi/rest/oauth/command-line, really whatever you come across or we talk about. compendium can have an entire section on nix that is a hundred pages and doesnt mention mpcx at all. you could write a short science fiction in there and i wouldnt mind. i'm not asking you to write a short science fiction story i'm asking for an overview intro and reference website and manual.

Acceptance criteria

  • Every mcpx theme named in this tracker maps to at least one filed, labelled issue in the batch (or an explicit 'not doing' note here).
  • Disagreements between themes are resolved or escalated on this issue; the tracker is kept current until the last themed issue closes.

Activity

  1. developing-today commented on Oct 28, 2026

    @developing-today
    developing-todayBot
    on Oct 28, 2026 – with developing.today
    Contributor

    CODE-827

  2. dezren39 commented on Oct 28, 2026

    @dezren39
    dezren39
    on Oct 28, 2026
    MemberAuthor

    History carried over from dezren39/darwin-nix#181 (verbatim, oldest first):

    @dezren39 · 2026-09-30T11:55:27Z

    Issues pass (2026-09-30, at 05c78b2). This tracker was written against 8001f23 and drafted
    corrections were never applied. They are applied now, plus everything that merged since.

    What changed:

    Nothing in ## Original notes was touched; the block is byte-identical to the previous revision.

    @dezren39 · 2026-09-30T12:24:42Z

    Issues pass, architect revision (2026-09-30, at 05c78b2). This supersedes the 11:53 revision above it, which applied an early draft of this pass; everything in that revision is kept or corrected here. What changed and why:

    @dezren39 · 2026-09-30T12:58:55Z

    Issues pass, final reconciliation (2026-09-30, at 05c78b2). The architect revision above is the substantive one and stands. Six corrections on top of it, plus the closing verification.

    Nothing in ## Original notes has been touched by any revision in this pass.

    @dezren39 · 2026-09-30T16:30:09Z

    Rows 2, 3 and 10: the decision records are merged. Each of those cells said "via a SURFACES decision record in docs/decisions/ (in flight)". They landed in #228, so the cells can now name a file:

    row collision record settles
    2 four hook vocabularies (#81, #82, #112, shipped script.*) docs/decisions/0001-hook-vocabulary.md a hook is where (on), when (phase), what runs, what its output may do (effect). Six phases and no others — the five shipped ones keep their names, observe is new and is the default because it is the only phase that cannot slow or change anything. Points come from one Go table the way api.Ops() enumerates routes, with a guard test that fires every point, so a point cannot be declared and dead the way call.started is. #81's exec point is named script.
    3 three autonomy dials (#111 repair.level, #112 hook effect, #113 prompt.mode: plan) docs/decisions/0002-autonomy-dial.md one ordered dial — off → advise → ask → propose → apply → run — with autonomy.max as a daemon ceiling and per-call settings ClampedBy it. Two rules hold at every level: no level skips a consent gate, and no level lets mcpx exceed what the caller could have done. prompt.mode becomes prompt.autonomy; #111's repair.level and #112's effect map onto the same words.
    10 nobody owns the declared-vs-enforced boundary (#82, all) docs/decisions/0003-declared-vs-enforced-capabilities.md three kinds of declaration — promise (delivered; an undelivered one is #177, not a state), restriction (either enforced, with a test that tries it and sees the refusal, or advisory, and then every surface showing it says so — no third state), hint (true, and recognisable as a hint). "Declarable now, enforceable later" is advisory. The daemon is the only enforcer; SURFACES owns the declarations in api.Boundaries(). Row 10 closes: the boundary has an owner, a table and two tests.

    The mapping tables at the end of each record are the part worth reading before editing any of the issues in those rows — they list every competing term, where it came from, and what it becomes.

    One thing 0003 turns up that this tracker should know: #177 gains four instances — the TCP listener, script.permissions on Bun and Node, the inert auth block, and restart's idempotentHint. The first is a security issue rather than a tidiness one; there are no users yet, which is the only reason it is not urgent.

    Also delivered in #228, because 0003 requires it: Op.Admin's tool description said only "Privileged: this changes the daemon rather than reading it", which reads like a permission something checks. Nothing does — every endpoint is unauthenticated. It now says "Advisory: the daemon does not check who calls it", held by a test across all 15 admin operations.

    @dezren39 · 2026-09-30T16:58:24Z

    Collisions 2, 3, 5, 7, 10 and 13 are decided in pkgs/mcpx/docs/decisions/ (merged in #228), each with context, options A/B/C, the decision, consequences per issue and a mapping table:

    • 0001 -- rows 2, 7, 13: the shipped launcher phases (before/prefix/onSuccess/onError/suffix, plus observe) are the one hook vocabulary; hooks are one hooks setting; the exec frame order is fixed.
    • 0002 -- rows 3, 5: one dial off < advise < ask < propose < apply < run, instantiated per feature (prompt.autonomy, repair.autonomy, hook effect); ClampedBy is an internal/settings capability with one daemon ceiling autonomy.max, lowering and reporting rather than refusing.
    • 0003 -- row 10: SURFACES owns the declared-vs-enforced boundary. A restriction is enforced (with a test that tries to get round it) or advisory (and says so on every surface); "declarable now, enforceable later" means advisory.

    Each affected issue (#81 #82 #110 #111 #112 #113 #114) has a comment saying what changes in it.

  3. dezren39
    added
    enhancementNew feature or request
    queue/queuedHas a queued task in the Supabase agent queue
    status/needs-triageNot yet triaged; needs a first look
    kind/enhancement
    priority/normalOrdinary priority (the default)
    effort/lLarge: multi-day or open-ended; expect staged check-ins
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 28, 2026

  4. dezren39 commented on Oct 28, 2026

    @dezren39
    dezren39
    on Oct 28, 2026
    MemberAuthor

    Intake review

    🤖 Agent note · filed

    Notes: Filed in the large mcpx filing batch of 2026-10-28 21:59–22:24Z and already carries a queued triage task — it is not orphaned. Verified live at intake: no merged PR references this issue and it was filed under an hour ago, so nothing can have resolved it yet. Acceptance criteria appended to the body from the issue's own stated scope; original body preserved verbatim above it.

    Risks: Tracker-level scope overlaps its sibling batch issues — the triage pass must dedupe against them before any implementation packet is written, and split rather than implement if the scope is multi-PR.

    Suggested approach: Triage first (task 2803): confirm the boundary against the sibling issues, then enqueue one scoped packet per deliverable slice.

  5. dezren39 commented on Oct 28, 2026

    @dezren39
    dezren39
    on Oct 28, 2026
    MemberAuthor

    🤖 Agent note · correction

  6. github-actions
    assigned
    dezren39
    on Oct 28, 2026
  7. dezren39
    added
    work/assignedQueue worker lifecycle state
    and removed
    status/needs-triageNot yet triaged; needs a first look
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 31, 2026

  8. 28 remaining items

  9. dezren39
    added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    and removed
    work/assignedQueue worker lifecycle state
    on Nov 4, 2026

  10. dezren39 commented on Nov 4, 2026

    @dezren39
    dezren39
    on Nov 4, 2026
    MemberAuthor

    🤖 Agent note · picked up

  11. dezren39
    added sub-issues on Nov 4, 2026

  12. dezren39 commented on Nov 4, 2026

    @dezren39
    dezren39
    on Nov 4, 2026
    MemberAuthor

    🤖 Agent note · triaged — native tracker structure restored

  13. dezren39
    removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

effort/lLarge: multi-day or open-ended; expect staged check-insenhancementNew feature or requestkind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)source/creatorFiled by the new-issue-creator jobstatus/triagedTriaged and routed (see agent note)task/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions