Name snuggles-inventor as the code-generation owner.

Assistant: grok
Assistant-Session: 01a0d25d-d358-7e13-b84a-d007fbb7e34f

INTENT.md

@@ -87,7 +87,7 @@ environments, compose stacks, and operator smoke paths. Conversely, wise-validat
 **depends on** sand-boxer (or a compatible establishment API) for environments —
 never the reverse.
 
-Other peers (glas-harness, snuggle-inventor, activity-core, CI) are equally
+Other peers (glas-harness, snuggles-inventor, activity-core, CI) are equally
 optional consumers of the same API.
 
 ---
@@ -115,7 +115,7 @@ projects own adjacent concerns. Integration is contractual — they **request**
 sandboxes; sand-boxer **establishes** them.
 
 Per-sibling integration contracts: `docs/integrations/` (glas-harness,
-wise-validator, snuggle-inventor).
+wise-validator, snuggles-inventor).
 
 ### glas-harness — agent harness
 
@@ -151,7 +151,7 @@ Lineage: wise-validator replaces the **validation half** of
 `the-custodian/e2e-framework/`; sand-boxer already owns the provision/teardown
 half (`ext.compose-ssh`).
 
-### snuggle-inventor — code generation
+### snuggles-inventor — code generation
 
 **Owns:** Code generation, modernization pipelines, tech-spec and planning
 artifacts, PR-oriented output, human-in-the-loop review gates.
@@ -159,14 +159,14 @@ artifacts, PR-oriented output, human-in-the-loop review gates.
 **Does not own:** Sandbox infrastructure, environment bootstrapping authority,
 secret stores, runtime metering.
 
-snuggle-inventor may attach Blitzy-style **setup instructions** and secret
+snuggles-inventor may attach Blitzy-style **setup instructions** and secret
 references as profile inputs. sand-boxer resolves secrets at the provision
 boundary; generated code never transits sand-boxer APIs.
 
 ### Boundary diagram
 
 ```
-  glas-harness          wise-validator         snuggle-inventor
+  glas-harness          wise-validator         snuggles-inventor
   (agent harness)       (e2e + health)         (code generation)
         │                     │                      │
         └─────────────────────┼──────────────────────┘
@@ -261,7 +261,7 @@ Self-hosted extensions record **allocation** (host, duration), not external spen
 |---------|--------|-----------------|
 | Agent gateway, tools, memory, channels | **glas-harness** | Customer API |
 | E2e tests, health checks, validation | **wise-validator** | Customer API |
-| Code generation, tech specs, AAP | **snuggle-inventor** | Customer API |
+| Code generation, tech specs, AAP | **snuggles-inventor** | Customer API |
 | When work runs | `activity-core` | None |
 | What tasks exist | `state-hub` | Registers lifecycle only |
 | Tunnels | `ops-bridge` | Consumer |
@@ -325,7 +325,7 @@ follows evidence.
 ## Intended users
 
 - **Human operators (`adm`)** — profiles, hosts, extensions, credits, lifecycle
-- **LLM agents (`agt`)** — via glas-harness, snuggle-inventor, or direct API
+- **LLM agents (`agt`)** — via glas-harness, snuggles-inventor, or direct API
 - **Deterministic automations (`atm`)** — via wise-validator, activity-core, CI
 - **Extension authors** — implement backend adapters against the extension contract
 - **Platform integrators** — register capabilities, federate via reuse-surface
@@ -368,7 +368,7 @@ A mature sand-boxer is Coulomb's **default way to establish any sandbox**:
 
 - glas-harness requests agent dev sandboxes without choosing Docker vs Modal vs SSH
 - wise-validator *may* request validation environments; sand-boxer does not depend on it
-- snuggle-inventor requests build sandboxes with setup metadata and secret refs
+- snuggles-inventor requests build sandboxes with setup metadata and secret refs
 - activity-core and CI request bounded venues with consistent lifecycle visibility
 - Operators route spend across self-hosted and SaaS with one credits model
 - A Coulomb-native runtime — if warranted — wins on ops data, not speculation