docs(supply-chain): first-party skill repo + mother as paid tier

External skill marketplaces (clawhub.ai, skills.sh, lobehub, browse.sh,
claude-marketplace) are unvetted instruction streams ingested into an agent's
context — a prompt-injection / supply-chain vector, the same class of risk as
`pkg install` from a random mirror, one layer up. Combined with the poudriere
plan, the conclusion is a first-party repository for BOTH layers.

- HIVE-ONBOARDING §10 (new): the trusted supply chain. pkg.clawdie.si (packages)
  gets a sibling first-party skill repo (proposed skills.clawdie.si). External
  sources become staging/review input, never a direct tenant runtime dep:
  curate → pin → sign → publish. Clarifies clawhub.ai is third-party, unrelated
  to pkg.clawdie.si (different layer + ownership).
- HIVE-ONBOARDING §5: mother expanded as the PAID product surface — paid tenants
  are provisioned first-party-only; that hardening is the thing worth paying for.
  §6 moat + §7 invariant + Status open-work updated to match.
- HOST-MATRIX §2: new "Registry & supply-chain provenance" table (first-party vs
  third-party per layer); mother-build row notes it serves pkg.clawdie.si.

Validation: prettier@3 --check; python3 scripts/layered_soul.py validate . — pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/HIVE-ONBOARDING.md

@@ -39,6 +39,9 @@ Open work, categorized:
   section in `pkg-list-jails.txt`).
 - **Cost/source-of-truth:** fill `docs/HOST-MATRIX.md` cost provenance rows before buying
   or retiring build capacity; compare OVH quotes/invoices against measured self-host power.
+- **Trusted supply chain (new, §10):** stand up first-party repos — `pkg.clawdie.si`
+  (poudriere) and a signed skill repo — so paid tenants run first-party-only skills and
+  packages instead of external marketplaces.
 
 **One-line plan:** run the first-proof runbook → then land #101/#102 for CLI driveability,
 #92 before promoting past scratch, and fill verified OVH/self-host cost data before buying
@@ -115,6 +118,17 @@ mother := resolve-identity (layered-soul)
 
 osa/FreeBSD/Bastille is the natural womb — cheap, dense, isolated jails.
 
+**Paid tier — the product surface.** `mother` is what a paying customer actually
+buys. Paste one key → `mother` births a private agent in an isolated jail and
+provisions it **exclusively from Clawdie's first-party supply chain**: curated
+skills from our own skill repository and packages from `pkg.clawdie.si`
+(see [§10](#10-planned-the-trusted-supply-chain--first-party-skills--packages)).
+A free/community path may opt into public skill marketplaces at the operator's own
+risk; the **paid** path is hardened to first-party-only sources. That hardening is
+both the safety guarantee and the thing worth paying for — not a separate feature
+bolted on, but the difference between "an LLM in a box" and "an agent whose every
+skill and package we curate and sign."
+
 ## 6. The product, and the moat
 
 > A customer pastes **one key** → gets a **private agent in an isolated jail** → that lean
@@ -130,6 +144,9 @@ behind one key — **capability routing is the differentiator.**
 - **debby / domedog** = capability lanes (specialized organs)
 - **Vaultwarden** = per-tenant nerve store
 - **clawdie-iso** = the shared body every jail boots from
+- **first-party supply chain** = curated skills + packages the agent feeds on
+  ([§10](#10-planned-the-trusted-supply-chain--first-party-skills--packages)), not
+  arbitrary public marketplaces — a second differentiator alongside routing
 
 ## 7. The security invariant (non-negotiable)
 
@@ -141,6 +158,11 @@ behind one key — **capability routing is the differentiator.**
 - Per-tenant blast radius = one collection. Scoped credential, never a master.
 - This is the same shape the domedog smoke test validated (bootstrap on host, `.env` is the
   output) — just made multi-tenant.
+- **Supply-chain trust is part of the invariant.** Secrets are not the only thing that
+  enters a jail — so do **code and instructions** (packages, and `SKILL.md` bundles the
+  agent will follow). Both come only from sources we control; external skill marketplaces
+  are untrusted input, vetted before they ever reach a tenant
+  (see [§10](#10-planned-the-trusted-supply-chain--first-party-skills--packages)).
 
 ## 8. [PLANNED] Lean MVP — and what NOT to build yet
 
@@ -179,6 +201,60 @@ None are technical blockers; all are paper-and-process:
 See [`HOST-MATRIX.md §4`](./HOST-MATRIX.md#%C2%A74-compliance-standing-constraints) for the
 four standing constraints that apply now (internal use).
 
+## 10. [PLANNED] The trusted supply chain — first-party skills + packages
+
+Two layers feed every agent, and **both are attack surface**:
+
+- **OS packages** — what the jail is built and patched from (`pkg` / poudriere).
+- **Skills** — `SKILL.md` instruction bundles ingested into the agent's context and
+  **followed by the model at runtime**.
+
+External skill marketplaces are community-sourced, unvetted, and mutable. Hermes already
+integrates several as read-only community sources — `clawhub.ai`, `skills.sh`, `lobehub`,
+`browse.sh`, `claude-marketplace` (see hermes-bsd `tools/skills_hub.py`). **A skill is
+literally instructions an LLM will execute**, so a hostile or compromised skill is a
+prompt-injection / instruction-smuggling vector: it can attempt to exfiltrate the tenant's
+one key, redirect tasks, or escalate through routed capabilities. That is the same class of
+risk as `pkg install` from a random public mirror — one layer up, and arguably worse,
+because the payload targets the agent's reasoning directly.
+
+> **Note on `clawhub.ai`:** despite the name, it is a **third-party** marketplace Hermes
+> only consumes (read/download via `https://clawhub.ai/api/v1`). It is **not** Clawdie
+> infrastructure and is **unrelated to `pkg.clawdie.si`** — different layer (skills vs OS
+> packages), different ownership (upstream we pull vs server we run).
+
+**Decision: Clawdie runs its own first-party repository for _both_ layers.** The poudriere
+plan (`pkg.clawdie.si`) is the package half; it gets a sibling for skills.
+
+| Layer       | First-party repo                                      | Curates / replaces           | Status                                   |
+| ----------- | ----------------------------------------------------- | ---------------------------- | ---------------------------------------- |
+| OS packages | `pkg.clawdie.si` (poudriere)                          | public FreeBSD `pkg` mirrors | [PLANNED] — `mother-build` host (matrix) |
+| Skills      | first-party skill repo (proposed `skills.clawdie.si`) | external skill marketplaces  | [PLANNED]                                |
+
+The pattern is identical for both: **an external source is a staging/review input, never a
+direct runtime dependency for a tenant.**
+
+```
+external source        review + pin + sign        first-party repo        agent pulls
+(clawhub, skills.sh,  →  (human / CI gate)      →   (we control)        →  (paid tenant:
+ public pkg mirror)                                                          first-party only)
+```
+
+- **Curate, don't proxy.** We pull a candidate skill/package, review it, pin a version,
+  sign it, and publish into our repo. Upstream edits never silently reach tenants.
+- **Pinned + signed.** Tenants resolve a fixed version from a repo whose signing key they
+  trust — the same trust-anchor idea as the SSH key planned for `pkg.clawdie.si`.
+- **Paid = first-party-only.** `mother` ([§5](#5-planned-the-mother-skill)) provisions paid
+  tenants exclusively from these repos. This is the concrete extension of the §7 invariant:
+  jails hold only resolved secrets **and** run only first-party code/instructions.
+- **Free/community** may opt into external marketplaces directly, at the operator's own
+  risk — that risk boundary is exactly what the paid tier removes.
+
+**What NOT to build yet** (same restraint as [§8](#8-planned-lean-mvp--and-what-not-to-build-yet)):
+no custom marketplace UI, no automated upstream-sync bot, no public skill-publishing for
+third parties. Smallest real path: stand up `pkg.clawdie.si`, then a **minimal signed skill
+repo `mother` can read**. Curation starts manual; automate only once it hurts.
+
 ---
 
 _See [`CAPABILITY-ROUTING.md`](./CAPABILITY-ROUTING.md) for the routing layer the moat rests

docs/HOST-MATRIX.md

@@ -99,11 +99,11 @@ IDs, account numbers, billing addresses, or payment details. If a provider is in
 an IP range, mark it `TBD` until the control panel or invoice confirms it.
 
 | Host / candidate                      | Provider                                                           | Plan / SKU                                | Region          | Monthly cost                          | Billing cycle | Role paid for                                                                                     | Source / proof                                                                | Status / notes                                                                                                                                   |
-| ------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------- | --------------- | ------------------------------------- | ------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| ------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------- | --------------- | ------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
 | **osa**                               | TBD (verify; OVHcloud is suspected but not invoice-confirmed here) | TBD                                       | TBD             | TBD                                   | TBD           | always-on orchestrator + board + Hermes gateway                                                   | operator invoice/control panel needed                                         | Existing always-on VPS; do not treat IP range as proof.                                                                                          |
 | **domedog**                           | TBD                                                                | TBD                                       | TBD             | TBD                                   | TBD           | Linux media/compute lane                                                                          | operator invoice/control panel needed                                         | Existing Linux VM; cost not tracked yet.                                                                                                         |
 | **debby**                             | self-owned laptop                                                  | —                                         | local           | utility/power TBD                     | —             | intermittent secondary agent + soul backup                                                        | local device + utility rate if needed                                         | Not an always-on hub; power cost only matters when left on.                                                                                      |
-| **mother-build** (candidate)          | proposed OVHcloud                                                  | TBD: Public Cloud hourly or Eco/dedicated | TBD             | TBD                                   | TBD           | FreeBSD build host / poudriere / Rust+zot builds                    | OVH quote needed before purchase                                              | Prefer on-demand if builds are infrequent; dedicated only if build demand justifies standing cost.                                               |
+| **mother-build** (candidate)          | proposed OVHcloud                                                  | TBD: Public Cloud hourly or Eco/dedicated | TBD             | TBD                                   | TBD           | FreeBSD build host / poudriere / Rust+zot builds → serves `pkg.clawdie.si` (first-party pkg repo) | OVH quote needed before purchase                                              | Prefer on-demand if builds are infrequent; dedicated only if build demand justifies standing cost.                                               |
 | **ML350p Gen8** (candidate/retire)    | self-hosted hardware                                               | owned hardware                            | local           | ~€53–63/mo @ 460 W high-load estimate | utility bill  | multitenant/build candidate; fallback if TCO beats cloud                                          | GEN-I + URO tariff research; fan/PSU label, not wall-metered                  | Use as planning band only; measure wall draw before committing tenants.                                                                          |
 | **vultr-svc** (Forgejo + Vaultwarden) | Vultr                                                              | TBD                                       | TBD (verify EU) | TBD                                   | TBD           | git mirror (layered-soul + hermes-soul) + Vaultwarden secrets store                               | DNS code/vault.smilepowered.org → Vultr (verified 2026-06-20); invoice needed | Off-OVH backup target (good) BUT Forgejo + Vault share one box → SPOF for backups AND secrets; needs own off-box backup + EU-region verify + MFA |
 
@@ -124,6 +124,26 @@ meter proves otherwise.
   draw; **~€59–63/mo** if 460 W is output-side load at ~90–85% PSU efficiency.
 - Annualized planning band: **~€640–760/year**.
 
+### Registry & supply-chain provenance
+
+What an agent consumes splits into two layers, each with its own registry. Record which
+are **first-party** (we run/sign them) versus **third-party** (external, untrusted until
+vetted). Rationale and the curation flow live in
+[`HIVE-ONBOARDING.md §10`](./HIVE-ONBOARDING.md#10-planned-the-trusted-supply-chain--first-party-skills--packages).
+
+| Registry / source                                         | Layer       | Ownership   | Direction    | Status                                |
+| --------------------------------------------------------- | ----------- | ----------- | ------------ | ------------------------------------- |
+| `pkg.clawdie.si` (poudriere)                              | OS packages | first-party | we host/sign | [PLANNED] — on `mother-build`         |
+| first-party skill repo (proposed `skills.clawdie.si`)     | skills      | first-party | we host/sign | [PLANNED]                             |
+| `clawhub.ai` (`https://clawhub.ai/api/v1`)                | skills      | third-party | we pull only | external — Hermes `ClawHubSource`     |
+| `skills.sh`, `lobehub`, `browse.sh`, `claude-marketplace` | skills      | third-party | we pull only | external — Hermes community sources   |
+| public FreeBSD `pkg` mirrors                              | OS packages | third-party | we pull only | external — to be fronted by poudriere |
+
+**Key point:** `clawhub.ai` is **not** Clawdie infrastructure and is **unrelated** to the
+planned `pkg.clawdie.si` — different layer (skills vs OS packages) and different ownership
+(upstream we consume vs server we operate). Paid tenants are provisioned from first-party
+rows only.
+
 ---
 
 ## 3. Per-host detail (expand as needed)