skills: publish maxplayer-muse-buyer, the Muse layer of the buyer path

[maxy-player]

What this is

The Muse layer of the buyer path, as one new public skill: maxplayer-muse-buyer.

A Muse account has a workspace, a scheduler and no shell of its own. The existing
maxplayer-buyer-operate skill assumes none of that, and this one does not restate it —
it adds only what is Muse-specific: where the bundle installs, why MAXPLAYER_HOME has to
be set on the MCP server process, the two-step funding that needs a human's number before
the first invoice, the approval every paid post needs afresh, and what "paid" means when
the daemon settles in the background.

Buyer only. No seller bridge, no scheduler, no seller docs, no seller registry entry.

Scope

New	web/app/.well-known/skills/muse-buyer/{skill.md, references/verification.md, references/settlement.md}
New	web/app/test/muse-buyer-skill.test.mjs
Changed	web/app/.well-known/skills/index.json — one entry added after buyer-operate; all seven existing entries untouched
Changed	web/app/.well-known/skills/default/skill.md — one homepage link, which test/build.test.mjs requires for any indexed skill

6 files, +694/−0. No source, build, crate or CI change.

Source-checked against this tree at 0.5.8

The earlier draft of this material leaned on 0.5.7 field reports. Every claim below was
re-read in this base's source:

• post_job requires task, output, amount_sats. Every published example carries
  output, because a post without it is refused.
• payment is a declared enum (sat|none) here, and the buyer path enforces it: an
  unrecognised value is refused, and payment=none demands amount_sats=0. The free-job
  example obeys that rule.
• The declared schema sets additionalProperties: false, but PostJobParams deserializes
  without deny_unknown_fields. The skill separates the advertised contract from
  proven enforcement rather than promising a mistyped optional field is caught.
• award_claim's required job_id/claim_id are shown, with the write-once award and
  the first-call max_sats ceiling explained.
• maxplayer buyer refuses --home and names MAXPLAYER_HOME; wallet setup with
  no amount silently requests 21 sats. The skill therefore has the human pick the number
  first and invokes setup exactly once.
• references/settlement.md covers the two things that cost people money: the buyer
  watcher settles delivered jobs in the background with no collect call, and collect
  can pay and then fail to materialise — whose supported recovery is re-running collect
  for the same job_id. There is no blanket no-charge assurance anywhere in the bundle,
  and a test forbids one being added.

Offline gate

One deterministic command. No network, relay, mint, daemon or sats:

node --test web/app/test/muse-buyer-skill.test.mjs

20 pass (node v26.5.0). It checks a fresh-home install from the skill's own manifest
with every link resolving locally, manifest/shipped-file agreement in both directions, no
absolute home path or key or invoice or balance in anything shipped, the 10,000-character
core budget, the pinned version, every published example against the schema read out of
this tree's mcp.rs, and the discovery index keeping every pre-existing entry.

Several tests fail loudly if the source moves under them — the free-job rule, the
--home refusal test names, the 21-sat default, the absence of deny_unknown_fields — so
a claim going stale becomes a red test instead of a wrong instruction.

node --test web/app/test/build.test.mjs also stays green (8 pass), which is what proves
the new entry reaches the built discovery document.

Disclosures

• The clean-account Muse acceptance gate is UNPASSED. Nobody installed this into a
  fresh Muse account, discovered it there, funded a wallet, posted a job or collected a
  delivery. The offline suite is a bundle-and-schema gate and is labelled as one.
  references/verification.md states the tier of every claim and exactly what would close
  the gate.
• Tier-2 material is field-reported from one operator's box on 0.5.7, a different
  version from this base, and is labelled field-reported wherever it appears.
• No live purchase, no wallet access and no spend of any kind was performed for this PR.
• Where an account cannot reach the relay by a supported route, the skill names a blocker.
  It deliberately publishes no tunnel, /etc/hosts overlay or proxy workaround.

Relationship to #985

#985 stays held as the earlier seller/mixed work; this branch is buyer-only and cut fresh
from current main, so the two do not overlap in file scope. Nothing here depends on the
seller bridge landing.

Draft: human review and human merge required.

Update — advisor R1–R5 corrections (head 9661fcf)

Second commit on the same branch, applying the review verdict on 834d17de with no
scope change: buyer only, seller work untouched.

• R1 funding. wallet setup's printed quote_id is now shown, and mint-complete
  takes it positionally — without exactly one quote id it exits USAGE_ERROR, so the
  previous bare command was unusable.
• R2 targeting and approval. Every post_job example picks a target mode
  (seller_pubkey or untargeted: true); a post with neither, or both, is refused in
  job_lifecycle.rs. The approval gate is five items including who may take the job,
  a free job now needs its own yes for publishing the task text publicly, and a
  max_sats the schema would accept is stated not to be new authority.
• R3 install and setup. The manifest is a source → installed-path mapping whose core
  lands as uppercase SKILL.md; the required buyer-operate companion is mapped and
  fetchable; the MCP prerequisite ships a launchable registration (maxplayer mcp with an
  absolute MAXPLAYER_HOME), with Muse-side registration labelled Not verified.
• R4 tests. The schema reader now parses declared types, enums, minima and maxima
  rather than field names, and the checker is proved by negatives (string amount_sats,
  invalid payment, non-boolean untargeted, undeclared field, missing task). New
  negative coverage: missing target mode, bare mint-complete, install entry point,
  companion closure. The version assertion is exact equality against Cargo.toml, and any
  other stated maxplayer version fails unless labelled a field report.
• R5 free jobs and recovery. references/settlement.md scopes the pay/attempt_id
  language to paid jobs, documents the free response shape (state: "none", null
  attempt_id, amount_sats: 0, no spent_total_sats) and says the missing field is
  not a zero lifetime spend. Retry is described as preserving the pinned award,
  probe-only after expiry and able to stay unresolved, with recovery bound to the same
  job id and MAXPLAYER_HOME.

skill.md was trimmed to 9,990 characters to stay inside its own 10,000-character budget
after these additions; the removed text was detail that already lives in the references.

Gate on this head: node --test web/app/test/muse-buyer-skill.test.mjs → 30 pass, 0
fail, exit 0 (was 20/0/0 at 834d17de; the ten new tests are the R4 negatives and the
R1/R3/R5 assertions). Nothing else was run: the delta touches no discovery entry or
homepage link.

The clean-account Muse acceptance gate remains UNPASSED, and no spend, wallet access
or live posting occurred for this update either.

Update 2 — R3/R4 residuals and R5 consistency (head 5143ca8)

Third commit on the same branch. Scope: the residuals the second review named, nothing
else. Seller work stays paused.

Corrections to what Update 1 above claimed. Two of its claims were ahead of the code
and are now made true rather than left standing:

• it said the schema reader parses declared maxima — it kept a maximum only when the
  source wrote it as digits, so get_job.timeout_secs.maximum = long_poll::WAIT_FOR_CAP_SECS
  became null and an example with timeout_secs: 11 would have passed while the server
  refuses anything above 10;
• it described injected negatives for target, quote and install, but those three checks
  only inspected the shipped positive artifacts.

R3 — self-contained bundle. The required buyer-operate companion install is
removed rather than repaired. That was the narrower of the two options the review
offered, and it ends the contradiction directly: nothing this gate never checks can ship
next to the skill telling the reader that model is a preference (it is a hard award
filter), that a retry converges (an expired attempt is probe-only), or to hand off to a
debug-buying page that was never mapped. The core now states it needs no other skill and
that it governs where older buyer material disagrees. A test asserts no manifest row
and no markdown link leaves the bundle, and that no other skill is named as a dependency.
The discovery description was updated to match, which is why build.test.mjs was re-run.

R4 — bounds resolved or failed closed. A bound written as a Rust constant is resolved
from the source that defines it; an unresolvable name fails the gate instead of
silently vanishing. Array items types are checked or fail closed. New negatives, each
asserted to be caught: below-minimum (amount_sats: -1, timeout_secs: 0),
above-maximum (timeout_secs: 11), out-of-enum wait_for, a value exactly at the cap
that must pass, a post with no target mode, a post with both, a bare mint-complete
carrying only flags, and three broken install manifests (no entry point, lowercase entry
point, flattened reference path). The version scan now checks every stated version and
binds the field-report exemption to the matched line, closing the loophole where one
Tier-2 line licensed a stale claim elsewhere.

R5 — bundle consistency. references/verification.md qualifies
accept → verify → pay → materialise and attempt-id idempotence as the paid path,
adds the free response shape and the probe-only expired-retry limit as source-checked
rows, and narrows the offline-suite description to the schema features the gate actually
reads.

Gates on this head: node --test web/app/test/muse-buyer-skill.test.mjs → 34 pass, 0
fail; node --test web/app/test/build.test.mjs → 8 pass, 0 fail (run because the
discovery description changed). History: 30/0/0 at 9661fcf, 20/0/0 at 834d17de.

skill.md is 9,982 characters. Clean-account Muse install/discovery/funding/post/collect
proof remains UNPASSED and needs separate human authorisation. No spend, wallet
access, live posting, main push, merge or deploy occurred for this update.

[vercel]

Someone is attempting to deploy a commit to the MakePrisms Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
mobee	Ready	Preview	Sep 10, 2026 1:39pm UTC