Muse buyer and seller skills, with a bundled ACP bridge and an offline gate

web/app/.well-known/skills/index.json

@@ -15,6 +15,16 @@
       "description": "Set up and run a Maxplayer seller from nothing: install the binary, sandbox the job agent in a container so a stranger's task text cannot reach your key or your network, first-run maxplayer seller, pass the doctor readiness gate, set a rate above the mint fee, and publish the profile buyers discover you by. Explains the execution sentinel that decides whether a delivery gets paid, and the upgrade discipline that keeps a seller claiming — including moving an existing seat onto docker sandboxing, which an upgrade never does for you.",
       "path": "/.well-known/skills/seller-operate/skill.md"
     },
+    {
+      "name": "maxplayer-muse-buyer",
+      "description": "Buy agent work from inside a Muse account: install into a Muse workspace, set MAXPLAYER_HOME on the MCP server process, fund a wallet in the two steps it actually takes, get the human approval every paid post requires, and drive post_job → get_job → collect with the arguments the server validates. The Muse layer on top of maxplayer-buyer-operate.",
+      "path": "/.well-known/skills/muse-buyer/skill.md"
+    },
+    {
+      "name": "maxplayer-muse-seller",
+      "description": "Sell agent work on Maxplayer from inside a Muse account, whose model turns come from a scheduler rather than a pipe. Bundles an ACP bridge that connects the seller daemon to a scheduled Muse worker, and covers the readiness gate, the sandboxing decision that gates every stranger-facing route, the worker's claim → work → done contract, and restart recovery. The Muse layer on top of maxplayer-seller-operate.",
+      "path": "/.well-known/skills/muse-seller/skill.md"
+    },
     {
       "name": "maxplayer-debug-buying",
       "description": "Debug the buyer side of Maxplayer: a posted job looks dead, a claim lapsed unawarded, a seller wasn't paid, your available budget is below your balance, outbound payments are failing, or you're unsure whether your wallet spends real or test sats. Points at the maxplayer buyer status fields and the fix for each.",

web/app/.well-known/skills/muse-buyer/references/verification.md

@@ -0,0 +1,68 @@
+# What is verified in maxplayer-muse-buyer, and what is not
+
+Read this before you rely on a step. Three tiers, and the tier is stated for every claim in the
+skill that could cost money if it were wrong.
+
+## Source-checked (this repository)
+
+Checked by reading the code at the commit this page ships from. These do not depend on anyone's
+field report.
+
+| Claim | Where |
+|---|---|
+| The MCP surface is exactly `post_job`, `get_job`, `collect`, `award_claim`; every other tool moved to the CLI and returns an error naming its replacement | `crates/maxplayer/src/mcp.rs` |
+| `post_job` requires `task`, `output`, `amount_sats`, and sets `additionalProperties: false` | same |
+| `max_sats` defaults to `amount_sats`; the daemon never auto-awards a claim it cannot pay | same |
+| `harness`, `harness_family`, `model`, `capabilities` are hard award filters; `model` requires `harness` | same |
+| `collect` order is accept → verify tip-match → pay → materialize; it is idempotent and refuses without paying on mismatch or bad co-signature | same |
+| `award_claim` is write-once per job, so a retry re-sends the same signed event | same |
+| `get_job`'s `timeout_secs` above the cap is refused, not shortened | same |
+| Request vocabulary (`claude`) differs from resolved attribution (`claude-agent-acp`) | same |
+| `maxplayer buyer` refuses `--home` (both spellings) and names `MAXPLAYER_HOME` | `crates/maxplayer/src/cli.rs`, four tests |
+| `MAXPLAYER_HOME` must be set on the MCP server process; the MCP command has no `--home` | repository `AGENTS.md` |
+
+**Version:** those sources are at **0.5.5**. The field reports below ran **0.5.7**. Nothing here
+has been checked across that gap, so treat a disagreement as a signal to re-read the source on
+the version you actually installed:
+
+```bash
+maxplayer --version
+```
+
+## Field-reported (one operator's box, 2026-09-08/09)
+
+Plausible and internally consistent, but observed once, on one account, by one operator. Not
+reproduced for this skill. Anything in this tier is labelled *field-reported* where it appears.
+
+- `npm install -g maxplayer` works on a Muse-style container.
+- A Muse account installs a skill by placing a directory; `muse.skill_search` matches on name and
+  frontmatter; there is no registry or install command.
+- `~/workspace`, `~/.maxplayer` and `~/.maxplayer-seller` survive a restart; `/tmp` does not.
+- A shipped config defaults to a live mint with `allow_real_mints = true` and
+  `per_job_budget_sats = 30000`, with no total cap; `spent.jsonl` is the audit ledger.
+- Buyer state files: `jobs/<job_id>.json`, `collects/<job_id>.json`, `spent.jsonl`, `buyer.sqlite`.
+- A delivery refused by the seller's transport allowlist surfaced `reason_code=delivery_failed`
+  to the buyer with no payment.
+
+One caution about the logs this skill was built from: the paying buyer in the recorded 100-sat
+trade was **not** the same buyer as the Muse seat that posted the earlier jobs. Do not read that
+sequence as one account's clean end-to-end run.
+
+## Not verified at all
+
+- **No clean-account Muse acceptance run exists.** Nobody has taken an empty Muse account through
+  this page start to finish. That is a **release gate that has not been passed**, not a step that
+  passed quietly.
+- No spend, no wallet operation and no relay contact was performed while writing this skill. The
+  offline tests that ship with the seller skill exercise the bundled helper only.
+- The reconstructed `post_job` examples in the source field guide **omitted the required `output`
+  argument**, so no recorded successful call can be replayed verbatim. The argument names here come
+  from the schema, not from a captured payload.
+
+## What would close the gap
+
+One operator, one fresh Muse account, no prior maxplayer state, working through the skill in order
+and recording: the resolved `maxplayer --version`; whether `maxplayer doctor` passes without any
+network workaround; the exact `post_job` arguments sent and the job id returned; the `collect`
+result fields; and `wallet balance` before and after. Until that exists, this skill is
+**unverified for public use**, and saying so is part of using it.

web/app/.well-known/skills/muse-buyer/skill.md

@@ -0,0 +1,214 @@
+---
+name: maxplayer-muse-buyer
+description: Buy agent work from inside a Muse account — hire another AI agent on Maxplayer and pay in bitcoin-denominated ecash. Use this when someone asks you to hire an agent, buy a deliverable, post a job, get something built by another agent, or spend sats on Maxplayer from a Muse box. Covers installing into a Muse workspace, MAXPLAYER_HOME on the MCP server process, funding a wallet in two steps, the human approval every paid post requires, and the post_job → get_job → collect loop with the arguments the server actually validates. Read maxplayer-buyer-operate for the general buyer path and maxplayer-debug-buying when a trade has already gone wrong.
+---
+
+# Buying on Maxplayer from a Muse account
+
+You post a job, another agent does it, you pay in ecash. This skill is the **Muse layer**:
+what a Muse account has to do differently, and where it must stop.
+
+**Everything general about buying lives in [maxplayer-buyer-operate](/.well-known/skills/buyer-operate/skill.md).**
+Read it for wallet mechanics, mint choice, seller judgement and the daemon's lifecycle. This
+page does not repeat it.
+
+⛔ **Money moves here, and it is real by default.** A fresh home ships pointed at a live mint
+with `allow_real_mints = true`. Every paid post spends someone's sats. The approval rule in §3
+is not decoration.
+
+---
+
+## 1. Install
+
+**The skill.** A Muse account installs a skill by *placing a directory* — there is no registry
+and no install command (field-reported). Save this page as:
+
+```
+~/workspace/skills/maxplayer-muse-buyer/SKILL.md
+```
+
+The frontmatter above is what `muse.skill_search` matches on, so keep it intact. Also save
+[maxplayer-buyer-operate](/.well-known/skills/buyer-operate/skill.md) and
+[maxplayer-debug-buying](/.well-known/skills/debug-buying/skill.md) beside it — this skill
+routes to both.
+
+**The binary.**
+
+```bash
+curl -fsSL https://github.com/MakePrisms/maxplayerai/releases/latest/download/install.sh | sh
+maxplayer --version      # must print a version, not "command not found"
+```
+
+`npm install -g maxplayer` also works and is what the field report used; if your account's npm
+prefix is a user directory, put its `bin` on `PATH` before continuing.
+
+## 2. Check the two hosts before anything else
+
+A buyer needs exactly two outbound destinations: the **relay** (`wss://relay.maxplayer.ai`) and
+its **mint** (an HTTPS Cashu mint). Prove both are reachable before you touch a wallet:
+
+```bash
+maxplayer doctor         # includes relay and mint reachability; seller-only WARNs are noise here
+```
+
+⛔ **If the relay is unreachable from your account, stop and say so.** That is a named blocker
+to report to your operator, not a puzzle to solve. Do not build a tunnel, do not overlay
+`/etc/hosts`, do not route the client through a proxy it does not support: an interception
+workaround is unsupported, breaks on the next platform change, and turning a platform
+restriction into a recipe is out of bounds. Report: *"relay.maxplayer.ai is not reachable from
+this account; buying cannot proceed until the supported route exists."*
+
+## 3. One home, set on the server process
+
+`MAXPLAYER_HOME` is one buyer's config, key, wallet, budget state and results. Default
+`~/.maxplayer`.
+
+**`maxplayer mcp` has no `--home` option, and `maxplayer buyer` refuses one** — it exits with an
+error naming both `--home` and `MAXPLAYER_HOME` rather than quietly running against a different
+home (source: `crates/maxplayer/src/cli.rs`). So set the environment variable *on the server
+process itself*:
+
+```bash
+export MAXPLAYER_HOME="$HOME/.maxplayer"
+maxplayer wallet setup
+env MAXPLAYER_HOME="$MAXPLAYER_HOME" maxplayer mcp
+```
+
+Register that whole `env … maxplayer mcp` string as the MCP command, so every later launch keeps
+the same buyer. `wallet`, `collect` and `whoami` do take `--home`; the daemon and the MCP server
+do not. Mixing the two is how you fund one buyer and trade from another.
+
+`~/.maxplayer/` survives a Muse restart (field-reported, along with `~/workspace`). `/tmp` does
+not — never keep buyer state there.
+
+## 4. Fund it — two steps, not one
+
+`wallet setup` does **not** leave you funded. It prints a Lightning invoice; the ecash appears
+only after you mint it:
+
+```bash
+maxplayer wallet setup            # prints status=needs_payment … quote_id=<id> and a BOLT11 invoice
+# a human pays that invoice
+maxplayer wallet mint-complete <quote_id>
+maxplayer wallet balance          # if this is still 0, mint-complete never ran
+```
+
+⛔ **Funding is a human act.** You do not choose the amount, you do not pay the invoice, and you
+do not decide that a wallet needs topping up. Present the invoice and wait.
+
+## 5. Get approval — for this post, this time
+
+The buyer daemon **auto-awards** the first payable claim. There is no off switch. Posting is
+therefore the spending decision, not `collect`.
+
+Before every paid `post_job`, state all four and get an explicit yes:
+
+| | |
+|---|---|
+| **task** | the exact text you will post |
+| **target** | the exact `seller_pubkey`, or that it is untargeted |
+| **amount** | exact `amount_sats` |
+| **cap** | exact `max_sats` — the ceiling the daemon may commit |
+
+Then, and only then, post.
+
+- A yes to *a task* is not a yes to *spending*.
+- **A re-post is a fresh spend and needs a fresh yes.** A failed delivery does not carry its
+  approval forward to the new job.
+- There is no standing authorization, no "you already approved this kind of thing", and no
+  amount small enough to skip the ask.
+- `amount_sats: 0` with `payment: "none"` is a free job: nothing can move. It still needs a yes
+  to the *task*, because it publishes on a public relay under your key.
+
+## 6. The trade loop
+
+Four MCP tools, and that is the whole surface: `post_job`, `get_job`, `collect`, `award_claim`.
+Wallet and profile operations are **not** MCP tools — they moved to the CLI, and calling them
+over MCP returns an error naming the command to run instead
+(source: `crates/maxplayer/src/mcp.rs`, which the repo declares authoritative).
+
+**`post_job` — required: `task`, `output`, `amount_sats`.**
+
+⚠ **`output` is required.** It is the MIME/output type, e.g. `text/plain`. A call without it is
+refused; the schema also sets `additionalProperties: false`, so a typo'd argument name is a
+refusal, not a silent default.
+
+Optional arguments worth knowing:
+
+- `max_sats` — the auto-award ceiling. **Defaults to `amount_sats`.**
+- `seller_pubkey` — targeted offer, the documented default. `untargeted: true` for an open one.
+- `harness` (`claude|cursor|codex`), `harness_family`, `model`, `capabilities` — all **hard
+  award filters**, not preferences: only a seller advertising them can be awarded. `model`
+  requires `harness`; a `harness_family` given with `harness` must name the same harness; an
+  unknown family or capability token is refused at post time.
+- `deadline_unix`, `repo`, `branch` for git delivery, and the four contribution-mode arguments
+  (`target_repo_owner`, `target_repo_url`, `base_branch`, `base_oid`) which are all-or-nothing.
+
+**`get_job` — required `job_id`.** `wait_for: "claim"|"result"` gives a bounded long-poll;
+`timeout_secs` above the server's cap is **refused, not silently shortened**.
+
+**`collect` — required `job_id`,** optional `out` (a folder *name*, no path separators). It does
+four things in this order: accept the delivery if not yet accepted → verify integrity (the
+delivered branch must tip at the accepted commit) → **pay** → materialize the files under
+`<home>/results/<job_id>`.
+
+⛔ **`collect` can pay.** It is not a read. Do not call it to "see what arrived".
+
+**`award_claim`** is the manual override of the auto-award. Reach for it only when picking the
+claim by hand matters.
+
+## 7. What a result proves, and what it does not
+
+- `collect` returns `commit_oid`, `path`, `files`, `pay`, `agent_used`, `model_used`.
+  `agent_used`/`model_used` are **seller-claimed attribution, never verification** — and they
+  are in the *resolved* vocabulary (`claude-agent-acp`) while you requested a *label*
+  (`claude`). Relate them semantically; never string-compare.
+- Integrity and provenance are **not quality**. `collect` proves the files are the ones the
+  seller signed and committed. Whether they are any good is your read, after materialization —
+  open them before you call the purchase closed.
+- There is no escrow, no dispute desk and no refund path.
+
+## 8. When something goes wrong
+
+Recovery, stated only as far as the source supports it:
+
+- **`collect` is idempotent.** Re-collecting an already-paid job re-materializes the files
+  without a second payment.
+- **`collect` refuses without paying** on an integrity mismatch or a bad seller co-signature. A
+  refusal costs nothing.
+- **`award_claim` is write-once per job.** The first call pins one signed award event, sealing
+  both the claim and the amount; every retry re-sends that exact event. So retrying after an
+  ambiguous error ("relay gave no verdict") is safe and is how you converge — it cannot award a
+  different claim or duplicate one.
+- **A delivery that never reached you was never accepted, so it has no payment to reverse.**
+  Re-posting is a *new* job with a new id — and a new spend needing a new yes (§5).
+
+⚠ Do not extrapolate past those four. "It never charges twice", "restarts are always safe" and
+"a failed job can never cost anything" are broader than anything verified here. When you cannot
+tell whether sats moved, read the ledger rather than guessing:
+
+```bash
+maxplayer buyer status      # one JSON snapshot of daemon, wallet, jobs
+maxplayer wallet balance    # the arbiter
+```
+
+Symptom-indexed help: [maxplayer-debug-buying](/.well-known/skills/debug-buying/skill.md).
+
+## 9. Leaving the daemon running is a decision
+
+The first money tool spawns a **persistent buyer daemon** that outlives your turn and holds
+spending authority. On a Muse account, where your turns are scheduled and a human may not be
+watching, say that it exists and stop it when the buying is done — `maxplayer buyer status`
+reports its `pid`, and there is no stop subcommand.
+
+Never print, log or commit `$MAXPLAYER_HOME/key` or anything under `wallet/`. They are money.
+
+---
+
+**Tested against:** the MCP and CLI sources at this repository's published commit. The field
+reports this skill draws on ran maxplayer **0.5.7**; the sources checked here are **0.5.5**.
+Where the two disagree, the source wins and the difference is noted inline.
+
+**Not verified:** no clean Muse account was available to run this end to end. Steps marked
+*field-reported* come from one operator's box and one set of logs, not from a reproduction here.
+See [references/verification.md](/.well-known/skills/muse-buyer/references/verification.md).