987fdd16db
All checks were successful
ci/woodpecker/push/default Pipeline was successful
Make the admin's Claude Code agent skills available to the `emo` devvm user. Viktor asked to install Matt Pocock's skills for emo, starting with grill-me but covering the full set the admin already uses. The `npx skills` upstream has drifted off that set (diagnose -> diagnosing-bugs and write-a-skill -> writing-great-skills were renamed; caveman + zoom-out are no longer published), so reproducing it via npx is impossible and would also spray ~70 agent dirs into the user's home + add a GitHub-clone + unpinned-CLI dependency to the hourly root reconcile. Instead vendor a point-in-time snapshot of the 16 skills (scripts/workstation/claude-skills/) and copy them per-user, mirroring install_memory: install_skills() copies each skill into ~/.agents/skills/<name> (owned by the user) and symlinks ~/.claude/skills/<name> -> ../../.agents/skills/<name>. if-absent, additive, best-effort, scoped to the SKILL_USERS allowlist (emo). find-skills is from vercel-labs/skills (not Matt Pocock) but included since it is part of the admin's current set. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
37 lines
2.5 KiB
Markdown
37 lines
2.5 KiB
Markdown
# Deepening
|
|
|
|
How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**, **seam**, **adapter**.
|
|
|
|
## Dependency categories
|
|
|
|
When assessing a candidate for deepening, classify its dependencies. The category determines how the deepened module is tested across its seam.
|
|
|
|
### 1. In-process
|
|
|
|
Pure computation, in-memory state, no I/O. Always deepenable — merge the modules and test through the new interface directly. No adapter needed.
|
|
|
|
### 2. Local-substitutable
|
|
|
|
Dependencies that have local test stand-ins (PGLite for Postgres, in-memory filesystem). Deepenable if the stand-in exists. The deepened module is tested with the stand-in running in the test suite. The seam is internal; no port at the module's external interface.
|
|
|
|
### 3. Remote but owned (Ports & Adapters)
|
|
|
|
Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Tests use an in-memory adapter. Production uses an HTTP/gRPC/queue adapter.
|
|
|
|
Recommendation shape: *"Define a port at the seam, implement an HTTP adapter for production and an in-memory adapter for testing, so the logic sits in one deep module even though it's deployed across a network."*
|
|
|
|
### 4. True external (Mock)
|
|
|
|
Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port; tests provide a mock adapter.
|
|
|
|
## Seam discipline
|
|
|
|
- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a port unless at least two adapters are justified (typically production + test). A single-adapter seam is just indirection.
|
|
- **Internal seams vs external seams.** A deep module can have internal seams (private to its implementation, used by its own tests) as well as the external seam at its interface. Don't expose internal seams through the interface just because tests use them.
|
|
|
|
## Testing strategy: replace, don't layer
|
|
|
|
- Old unit tests on shallow modules become waste once tests at the deepened module's interface exist — delete them.
|
|
- Write new tests at the deepened module's interface. The **interface is the test surface**.
|
|
- Tests assert on observable outcomes through the interface, not internal state.
|
|
- Tests should survive internal refactors — they describe behaviour, not implementation. If a test has to change when the implementation changes, it's testing past the interface.
|