Skip to content

mcpx docs: overview, quick start, install page and 'now what' #1878

New issue
New issue
Closed
Closed
mcpx docs: overview, quick start, install page and 'now what'#1878
Assignees
dezren39
Labels
status:done

Description

@dezren39
dezren39
opened on Oct 28, 2026

Relocated from dezren39/darwin-nix#157 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).

Parent: #92

Summary

The three pages behind the home page's two big links, plus the install page they point at:

  1. Overview -- why you would install mcpx (the notes' three reasons, expanded) and one architecture
    picture.
  2. Install -- every channel the notes list, with an honest status column, and the "install as" choices
    (just run the binary, per-user or per-host, local host, system service, persistent daemon).
  3. Quick start -- the agent loop from AGENTS.md (ls, search, types, run/exec) in under one
    screen, every command real.
  4. Now what -- a short page of links into level 2 (Bump golang.org/x/crypto from 0.16.0 to 0.17.0 in /sources/data #94).

Each page must pass the note-line-8 test: a reader "skimming while doing 3 different things" gets the point
from headings, the diagram and the command blocks alone. Prose is the second layer.

Original notes

  • documentation
    • make a book using whatever is the most common and simple modern choice
      • 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
              • quick start
              • now what

Current state (what mcpx does today, with file refs)

  • No overview, install or quick-start page exists. The nearest material: the top of docs/story.md
    (a narrative, story.md:1-296), AGENTS.md (the loop, 109 lines), package.nix meta.longDescription,
    docs/dependencies.md (what mcpx needs), docs/configuration.md (settings).

  • Commands. internal/cli/manual.go Commands() (:33) is the list behind mcpx help, mcpx man
    and the command table (32 entries). The dispatch table in cmd/mcpx/main.go:119-162 has seven more that
    mcpx help does not list: serve, openapi, adapter, registry, api, man, completion (plus the
    aliases list, namespaces, logs). Any page may use
    either set, but a command missing from mcpx help needs a note or a fix (the generated reference owns
    this: 🎨 Palette: Improve accessibility of editor search panel #144).

  • Only nix installs today. flake.nix:385 builds pkgs/mcpx/package.nix; flake.nix:494 exposes it as
    an app. Systems are nix-systems/default minus x86_64-darwin (flake.nix:207-211): aarch64-darwin,
    x86_64-linux, aarch64-linux. The wrapper puts git, deno, bun and node on PATH
    (package.nix postInstall), so a nix install is complete. No release or install script exists (amd host fails at evaluation: no outputHashes for p2panda-core-0.7.1 #158).
    A pkgs/mcpx/Containerfile exists since Phase 5: tag event bodies must travel with the event #182 and builds a working image locally (bun as its only
    runtime, git; docs/container.md), but nothing builds or publishes it.

  • Runtime prerequisite outside nix. mcpx run/exec need deno, bun or node; mcpx doctor fails the
    runtime check without one and warns if deno is absent ("the only runtime where --typecheck works",
    internal/cli/doctor.go:47-60). Node runs scripts with --experimental-strip-types
    (internal/runner/runner.go:100), so it needs Node 22.6 or later. git is optional (the repo and
    worktree scopes degrade to cwd, docs/dependencies.md).

  • Windows is not supported. syscall.SysProcAttr{Setpgid: true} and syscall.Kill are used without
    build tags (internal/runner/runner.go:413,428, internal/mcpclient/stdio.go:69,202;
    Setsid in internal/cli/client.go:312), which do not compile for GOOS=windows; package.nix declares
    platforms = lib.platforms.unix. WSL is the Windows answer today.

  • Daemon lifecycle settings (internal/settings/registry.go, internal/settings/wire.go):

    Setting Default Meaning
    daemon.autostart true any command that needs the daemon starts one
    autostart.idleExit 4h (internal/defaults/defaults.json:138) an auto-started daemon exits after this long idle
    daemon.idleExit 0s (never) for a daemon started deliberately (mcpx daemon)
    daemon.inline false last resort: run servers inside the CLI process, nothing pooled
    daemon.address 127.0.0.1 interface for the TCP listener
    daemon.port 0 (OS-assigned) TCP port
    daemon.endpoint empty (local socket) a client setting: talk to a daemon elsewhere; mcpx will not autostart it

  • Config search path (internal/config/config.go:542-579): MCPX_CONFIG if set; else, walking up
    from the working directory, .config/mcpx/config.json, .mcpx.json, .mcpx/config.json, .mcp.json;
    then $XDG_CONFIG_HOME/mcpx/config.json, ~/.config/mcpx/config.json, ~/.mcpx.json; then
    /etc/mcpx/config.json. So "per-host" configuration already exists as a file location, undocumented
    at level 1.

  • System service is status: proposed (story.md "Service installation", :2498): wanted
    mcpx service install emitting a launchd plist or systemd unit; "Until then the daemon starts on demand
    from any command, which is the supported path." (That entry also still asks for
    mcpx completions bash|zsh|fish, which shipped as mcpx completion; reported for 🎨 Palette: Add ARIA labels and live regions to search panel #150.)

Overview page

The why (expanded from note lines 9-17)

One section per reason, each: a display line, two or three sentences, one small proof (a command and its
real output, or a number from the story), one link to level 2.

Reason Proof to show Link
code mode: shareable, reusable scripts .mcpx/scripts/shot-flow.ts and mcpx run shot-flow <url> <outDir> (story.md:196-271) script page, #147
reclaim context: smarter, cheaper mcpx ls: "Seven namespaces, 43 tools, 171 tokens"; whole task ~4,600 tokens (story.md:142, :274) #153 for the evidence behind "smarter"
tame MCP: one config the mcpServers object is read as-is (mcpx init's starter comment) config page, #146
tame MCP: share with your tailnet mcpx daemon --address <tailnet-ip> --port 8899 + MCPX_DAEMON_ENDPOINT=http://<host>:8899 remote/transport page, #146
tame MCP: corral scripts, APIs, binaries named scripts; mcpx api tools --spec <url>; paths.adapters + mcpx adapter check (API and adapter tools are served over MCP only, not in the script client yet: #102) #147

The tailnet row must say plainly that the API is unauthenticated and that the network is the access
control (story.md:2120-2122).

The architecture picture (note line 19)

One diagram, readable in five seconds, that also answers "what is running on my machine":

agent / harness
  ├─ CLI            mcpx ls | search | types | run | exec        (unix socket)
  ├─ plugin         plugin/opencode (no binary needed, #53)      (unix socket or URL)
  ├─ MCP            /mcp on the daemon, or `mcpx serve --transport stdio`
  └─ HTTP           /v1/*  (OpenAPI at /v1/openapi.json)
        │
        ▼
    mcpx daemon  ── one per config; autostarts; idle-exits
        ├─ pooled MCP server processes (stdio) and remote servers (Streamable HTTP)
        ├─ OpenAPI specs and CLI adapters as tools (MCP surfaces only today, #102)
        └─ script runner: deno | bun | node subprocess
              └─ calls back into the daemon: Deno and Bun over the unix socket, Node over loopback TCP
                 (.github/workflows/mcpx.yml:52-54; internal/codegen/emit.go:263-291)

The ASCII above is the content, not the proposed rendering. Rendering approaches:

  • Approach A -- client-side Mermaid (least recommended). Most generators support it with a plugin
    (mdBook: mdbook-mermaid; MkDocs Material: native via superfences; Hugo: a render hook). Cheap to write.
    But it renders in the browser with a large JS bundle, shifts layout on load, shows raw text with JS off,
    and Mermaid's automatic layout makes nested boxes like the one above hard to control.
  • Approach B -- a hand-drawn SVG (middle). Best-looking and fully controlled, loads instantly. But it
    drifts: nobody updates an SVG when a surface is added, and the agent twin (Update module github.com/jackc/pgx/v5 to v5.9.2 [SECURITY] #120) gets an image with no
    text.
  • Approach C -- D2 rendered to SVG at build time (recommended). D2 is a single Go binary in nixpkgs,
    gives better control of nested containers than Mermaid, and renders to static SVG during the docs build,
    so the page has no diagram JS and the .d2 source ships in the agent twin as readable text. Works with any
    generator that can run a pre-build step (chore(deps): update rust crate actix-files to v0.6.10 - autoclosed #117); mdBook has an mdbook-d2 preprocessor. If
    chore(deps): update rust crate actix-files to v0.6.10 - autoclosed #117 picks a generator with first-class Mermaid, build-time Mermaid (mmdc, which needs headless
    Chromium) is the fallback.

Install page

Channels (note lines 20-22), in the notes' order

Primary row first (bash/nix/agent-prompt), then the secondary row. Status must be honest on the page and
update from the release pipeline, not by hand.

Channel Command on the page Status today Designed in
bash (install.sh) per-user curl -fsSL <short> | sh; system-wide curl -fsSL <short> | sh -s -- --system not started: no releases to download #158, #155 (command forms)
nix nix profile install github:dezren39/nix#mcpx; try without installing: nix run github:dezren39/nix#mcpx -- ls exists (flake output) this issue; #158 for a smaller flake
agent-prompt the rotating prompt + llms.txt URL not started #155, #120
pwsh (install.ps1) irm <short>/install.ps1 | iex blocked: mcpx does not build for Windows #158
rpm (and deb) dnf install ./mcpx-<v>.rpm not started #158
flatpak -- not recommended (see #158) #158
pkg open question: macOS .pkg, FreeBSD pkg, or Homebrew not started #158
docker docker run ... ghcr.io/<owner>/mcpx partly: pkgs/mcpx/Containerfile builds locally (docker build -f Containerfile -t mcpx ., #182); no published image #158 (publish), #134 (image design)
justThePlugin copy plugin/opencode/ into ~/.config/opencode/plugin/ (plugin README "Install") exists as a manual copy. Needs no mcpx binary on that machine: it finds a daemon over the unix socket (info files) or endpoint, and spawns mcpx --json status only as the last-resort rung 4 (bin: "" forbids even that; #44, fixed in #53; plugin/opencode/README.md:75-138). It does need a daemon running somewhere. #158, #148

System-wide command. The notes' home-page form sudo $(curl <short> | sh) is not used on any page: it
runs the installer unprivileged, then executes the installer's stdout as a root command line (#155,
"System-wide install command"). The install page shows curl -fsSL <short> | sh -s -- --system (the script
escalates only the copy into /usr/local/bin), with curl -fsSL <short> | sudo sh as the plain fallback for
environments where the script cannot call sudo itself. Same forms as #155; one source for both pages.

Nix caveats to state: the flake is the author's whole nix-darwin monorepo, so nix profile install fetches
and evaluates a large flake for one package (cost unmeasured; open question); x86_64-darwin is excluded.

Prerequisites box, above the table: a JavaScript runtime (deno recommended, bun, or node 22.6+) unless you
installed with nix (the container image ships bun); git recommended; macOS or Linux (Windows via WSL). Then "verify: mcpx doctor".

Install as (note lines 23-29)

Mode What to do Today
just exec the binary nothing: any command starts a daemon on demand (daemon.autostart true) and it exits after autostart.idleExit (4h) idle shipped
per-user binary in ~/.local/bin; config ~/.config/mcpx/config.json binary location awaits #158; config shipped
per-host binary in /usr/local/bin (install.sh --system); config /etc/mcpx/config.json (last on the search path) binary location awaits #158; config shipped but undocumented
optional: local host mcpx daemon --address <ip> --port <n> on one machine, daemon.endpoint / MCPX_DAEMON_ENDPOINT on clients (a client with an endpoint set never autostarts a local daemon) shipped
optional: system service launchd / systemd unit running mcpx daemon, with daemon.autostart false on clients so a stray second daemon cannot start proposed (story.md :2498); designed in #158
optional: persistent daemon mcpx daemon (foreground) or mcpx daemon --detached; daemon.idleExit defaults to 0 (never) for a deliberately started daemon shipped
fallback daemon.inline true: no daemon, servers live inside each command; slower, nothing pooled shipped, last resort

"local host" is read as "run the daemon on a host other clients reach (a LAN or tailnet address)". If the
note meant "bind to localhost only", that is already the default (daemon.address 127.0.0.1). Open
question below.

Quick start (under one screen)

The loop from AGENTS.md, preceded by the minimum setup. Every line is a real command
(internal/cli/manual.go); the server example is the one mcpx servers --help itself uses.

mcpx doctor                                   # runtime, config, daemon: what is missing and how to fix it
mcpx servers add fs -- npx -y @modelcontextprotocol/server-filesystem /tmp
mcpx ls                                       # namespaces, tool counts, state
mcpx search directory                         # find a tool by name or description
mcpx types fs                                 # TypeScript signatures for one namespace
mcpx exec 'emit(await fs.list_directory({ path: "/tmp" }))'

Then one step that makes it an agent tool, not a CLI demo: "give your agent AGENTS.md" (or install the
opencode plugin, #148).

Notes for whoever writes it:

  • Tool names come from the server; confirm list_directory with mcpx types fs when writing, and have
    CI run the block (Docs checks run in CI; see the testing trackers under Bump github/codeql-action from 2 to 3 #91 (CI pipeline Bump golang.org/x/crypto from 0.16.0 to 0.17.0 in /sources/launcher #95, integration/environments Bump golang.org/x/crypto from 0.14.0 to 0.17.0 in /sources/chat #97)).
  • The server example needs npx (Node). Someone with only deno or bun needs another first server; pick
    one that needs nothing extra, or show mcpx registry search <words> + mcpx registry add <name> --write.
  • mcpx init writes a starter .mcpx.json whose servers are placeholders (some-mcp-server), so
    mcpx ls after mcpx init shows an error row. Do not use init as step one of the quick start unless
    the starter changes.
  • Update dependency @playwright/test to v1.64.1 #79 proposes script.typecheck on by default for run; if that lands, the first run of a new script
    takes ~400 ms longer and a type error stops it before side effects. The quick start should show the
    default that ships, and say "deno" where typecheck needs it.
  • Output shown must be captured from a real run, not typed.

Now what (note line 48)

One short page, four to six links into level 2 (#94), each a question: "Where does config go?" (#146),
"How do I call mcpx from my harness / over MCP / over HTTP?" (#147), "How does the opencode plugin
work?" (#148), "Something is wrong" (mcpx doctor, mcpx status, #149 FAQ), "Everything, in
depth" (the compendium, #98).

Open questions

  • "local host" (note line 27): a daemon other machines reach, or loopback-only? The table assumes the
    former.
  • Does nix profile install github:dezren39/nix#mcpx evaluate in acceptable time from a cold machine, or
    does mcpx need its own small flake (or a flake at pkgs/mcpx) for users? Belongs with amd host fails at evaluation: no outputHashes for p2panda-core-0.7.1 #158.
  • Should the install page list justThePlugin beside binary channels, or under "harness integrations"?
    It is not an install of mcpx; it needs a daemon somewhere.
  • Which first server for the quick start works with every runtime?
  • Should the hidden commands (serve, api, adapter, registry, ...) be added to Commands() before
    the overview references them? (🎨 Palette: Improve accessibility of editor search panel #144)

Ease · Impact · Related

Ease: M (content from existing sources; the diagram pipeline is S once #117 is decided; honest
status needs #158 to exist first for most rows). Impact: high (the second and third pages of the
30-second path).
Depends on / related: #155 (links here; command forms), #158 (every "not started" row),
#117 (diagram tooling), #120 (agent twin), #144 (commands missing from mcpx help),
#146 #147 #148 #149 (now-what targets), #150 (story.md stale entries), #44 (closed, fixed in #53: plugin
without the binary), #134 (container image), #48 (other harnesses), #49 (CI), #79 (typecheck default), #102 (adapter/API tools not
in scripts), #94.

Security/auth deferred; see tracker.

Activity

  1. developing-today commented on Oct 28, 2026

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

    CODE-805

  2. dezren39 commented on Oct 28, 2026

    @dezren39
    dezren39
    on Oct 28, 2026
    MemberAuthor

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

    @dezren39 · 2026-09-30T07:20:23Z

    Integration pass. Placed in the DAG rooted at #181.

    @dezren39 · 2026-09-30T11:49:04Z

    Issues pass (2026-09-30, at 05c78b2).

  3. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    status/needs-triageNot yet triaged; needs a first look
    on Oct 28, 2026
  4. github-actions
    assigned
    dezren39
    on Oct 28, 2026
  5. dezren39
    added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue 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 29, 2026

  6. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    Agent note — triage verdict (queue task 2772): NOT a duplicate; scope confirmed; follow-up enqueued

    Dedupe (checked 2026-10-29, code issues, all states): no other issue covers these four pages. Neighbours, none a duplicate: #1894 is the level-1 tracker (parent — it tracks home + these pages, writes none); #1874 is the home page itself (the page that links here — a sibling, and its two big links are this issue's overview/quick-start); #1881 owns the release artifacts and install channels the install page must describe honestly (a dependency, not a cover); #1939 chooses the site generator and #1941 the Pages build (rendering concerns — the page content here is generator-agnostic markdown); the generated reference (#1843) owns the command table and the help/dispatch discrepancy the issue flags.

    Scope vs current main (origin/main 42796be) — confirmed, with updates:

    • Still no overview, install, or quick-start page exists anywhere under pkgs/mcpx (verified by tree search), and no book/site scaffolding exists yet (no book.toml/SUMMARY/mkdocs/hugo config) — the pages land as markdown source the chosen generator (mcpx docs: choose the site generator (mdBook, MkDocs Material, Docusaurus, Starlight, Hugo) #1939) will pick up.
    • Install reality is unchanged from the issue and must be stated honestly: nix flake app + package.nix (with git/deno/bun/node wrapped) and a locally-buildable Containerfile — no published release artifacts or install script until mcpx: release.yaml, release artifacts and the install channels the docs will promise #1881 lands; every other channel in the notes (bash installer, pwsh, rpm, flatpak, pkg, dockerhub, plugin-only) is a not-yet row in the status column, not a promise.
    • Source material stands as the issue describes: story.md's above-marker narrative for the overview, AGENTS.md's loop for the quick start (every command verified real against the current internal/cli/manual.go command list and cmd/mcpx/main.go dispatch at write time), package.nix meta + docs/dependencies.md + docs/container.md for install.

    Follow-up: implementation packet enqueued on this queue: write the four pages (overview, install, quick start, now-what) as markdown under pkgs/mcpx/docs/, each passing the skim test (point lands from headings + diagram + command blocks alone), quick-start commands all real and verified, install page status column honest per #1881, now-what linking into level 2 (#1898's page map).

  7. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    Agent note — triage closed (queue task 2772)

    • Verdict above stands: not a duplicate; the four level-1 pages are enqueued as the implementation follow-up on repo-health-code-pilot (dedupe key repo-health:v1:fix:developing-today/code:issue:1878).
    • This triage task is complete; the issue stays open for the follow-up.
  8. dezren39
    removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Oct 29, 2026

  9. 25 remaining items

  10. dezren39
    added
    status/in-progressQueue worker lifecycle state
    on Oct 30, 2026

  11. dezren39 commented on Oct 30, 2026

    @dezren39
    dezren39
    on Oct 30, 2026
    MemberAuthor

    🤖 Agent note · picked up (resumed)

    • Agent: queue worker (repo-worker-code), OpenChamber scheduled lane
    • Session / ID: queue task 3111
    • State: resumed from awaiting_ci on PR docs(mcpx): level-1 pages — overview, install, quick start, now-what (#1878) #2502 (queue/3111-1878-mcpx-level1-pages @ b4a88edd). Codex review on that commit reports no findings; CodeRabbit is rate-limited.
    • Revalidated: PR docs(mcpx): level-1 pages — overview, install, quick start, now-what (#1878) #2502 open, not draft, MERGEABLE; issue open; no held/Drew-owned restriction.
    • CI reality at 03:2xZ: every PR check has been QUEUED since 02:23:37Z (~60 min) and no non-skipped workflow anywhere in the repo has completed in that window — runner capacity outage, not a PR problem. Local verification runs while waiting.
    • Next: local go test ./... in pkgs/mcpx, then merge when checks are green or park again with the runner-outage evidence.

  12. dezren39 commented on Oct 30, 2026

    @dezren39
    dezren39
    on Oct 30, 2026
    MemberAuthor

    🤖 Agent note · verification pass while CI is down (queue task 3111, OpenChamber scheduled lane)

    Resumed from awaiting_ci on PR #2502 (queue/3111-1878-mcpx-level1-pages @ b4a88edd). Everything below was run locally on the laptop at that commit.

    1. The merge blocker is exactly one check, and it is the outage. gh api .../branches/main/protection → the only required context on main is basic: proxy port fallbacks (strict: false). On #2502 it has been queued since 02:23:37Z (60+ min) and no non-skipped workflow anywhere in the repo has completed in that window — the runner outage tracked in #1599. Nothing about this PR is blocking it.

    2. go test ./... in pkgs/mcpx at b4a88edd: 45 packages ok, 2 failures — both pre-existing on clean main, neither touched by this PR.

    • internal/settings TestEveryDocumentHasAChapter: 11 docs never placed in compendium.manifest.json (binary.md, cli.md, compare/*, examples.md, faq.md, interfaces.md, level-2-page-map.md, opencode-plugin-v2.md, plugins.md, scripts.md). Identical failure on clean main (a49def85) — this PR adds its four pages to the manifest correctly.
    • internal/defaults TestEveryDocumentationLinkResolves: 3 dead paths, all in files this PR does not touch — docs/compendium.md:59, docs/compendium.md:113 (docs/catalogue/), docs/opencode-plugin-v2.md:126 (pkgs/mcpx/plugin/opencode/v2/). Byte-identical output on clean main (a49def85).
    • Nothing else fails, internal/e2e and internal/daemon included: the four new pages introduce no test failure and every link they contain resolves. Precedent for merging past these two: docs(mcpx): define the compendium structure and map every document to a chapter (#1867) #2482 merged with basic: test red and the required check green.

    3. The quick start's loop runs end-to-end against a real build. go build ./cmd/mcpx at b4a88edd, then in a scratch config (--config /tmp/…/mcpx.json, --daemon-inline because this host's shared daemon does not start):

    $ mcpx --config … servers add fs -- npx -y @modelcontextprotocol/server-filesystem /tmp
added fs to …/mcpx.json; it is live now
$ mcpx --config … types fs
declare namespace fs { … create_directory … list_directory … }
$ mcpx --config … exec 'emit(await fs.list_directory({ path: "/tmp/opencode" }))'
{"content":"[FILE] 1123-pr.md … [DIR] qs-scratch …"}

    servers add → ls → types → exec works as the page describes, and fs.list_directory is a real tool of the current filesystem server. Every other command on the page (doctor, search, run, registry, init, daemon, api, adapter, status) is in internal/cli/manual.go Commands() at this commit.

    4. Review state. Codex at b4a88edd: has_any_findings: false; its two P2 threads from the earlier commit are outdated and were marked resolved this shift. CodeRabbit is rate-limited (no verdict).

    5. One nit, deliberately not fixed. The compendium.manifest.json entry for quick-start.md says "lines": 57; the file is 64 lines. Nothing validates the field (the test ignores it), and pushing a cosmetic fix would reset the required check and invalidate the reviewed SHA during an outage — recorded here instead.

    State: parked again awaiting the required check. Resume condition: basic: proxy port fallbacks green on b4a88edd (or on a new head with it green) → merge, complete as fixed_merged.

  13. dezren39
    added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    on Oct 30, 2026

  14. dezren39 commented on Oct 30, 2026

    @dezren39
    dezren39
    on Oct 30, 2026
    MemberAuthor

    🤖 Agent note · parked (merge queued)

  15. dezren39 commented on Oct 30, 2026

    @dezren39
    dezren39
    on Oct 30, 2026
    MemberAuthor

    🤖 Agent note · done — merged

  16. dezren39
    added
    status:done
    and removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    work/assignedQueue worker lifecycle state
    on Oct 30, 2026
  17. dezren39
    closed this as completedon Oct 30, 2026
  18. dezren39
    added a commit that references this issue on Oct 30, 2026

    feat(mcpx): publish the container image from the release (#1881 slice 6)

    218ec46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

status:done

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions