9b9084ffaf
Separate the single DEVELOPMENT.md into focused docs per audience: - cli/README.md — trim agent/interop sub-sections; user-facing contract, commands, data-dir, troubleshooting only. - cli/DEVELOPMENT.md — pared down to architecture, how-to-add-a-command, output conventions, testing, housekeeping. - cli/ROADMAP.md (new) — north-star, parity matrix, ordered milestones, non-goals. The live checklist for CLI feature parity. - cli/plans/2026-04-21-cli-distribution.md (new) — packaging strategy (Homebrew / winget / Scoop / deb / rpm / AUR / AppImage). - commons/plans/2026-04-21-event-renderer.md (new) — cross-cutting renderer design owned by commons, consumed by cli + desktop + android. Agentic routing: - .claude/skills/amy-expert/SKILL.md (new) — routing triggers + the five hard rules (thin-layer, JSON contract, non-interactive, data-dir-is-world, extract-before-adding). - references/command-template.md, extraction-recipe.md, output-conventions.md — bundled copy-paste references. Root .claude/CLAUDE.md: - Adds cli/ to the module list with its sharing rule. - Registers amy-expert in the skills table. - Documents per-module plans/ convention; freezes docs/plans/. https://claude.ai/code/session_01BQ5ZHwa8BAgEQ9zeM4CKhW
138 lines
5.5 KiB
Markdown
138 lines
5.5 KiB
Markdown
# Extract-from-Android recipe
|
|
|
|
The single most common reason an Amy feature request stalls: the
|
|
logic it needs lives in `amethyst/` with Android-only imports. You
|
|
cannot call it from `cli/`. You have to move it first.
|
|
|
|
This recipe is how.
|
|
|
|
## When to extract
|
|
|
|
Before writing a new command, ask:
|
|
|
|
1. Does the piece of logic I need exist in `quartz/` or `commons/`?
|
|
- **Yes** → use it.
|
|
- **No, but it's in `amethyst/`** → extract. This file.
|
|
- **No, it doesn't exist anywhere** → design it in `commons/`
|
|
directly. Write a plan doc under `commons/plans/` if it's a
|
|
new subsystem.
|
|
|
|
2. Never duplicate `amethyst/` logic into `cli/`. That's a debt you
|
|
will pay later when the Android caller drifts.
|
|
|
|
## Recipe
|
|
|
|
Land this as its own commit, **before** the commit that adds the
|
|
CLI command.
|
|
|
|
### Step 1 — Find the class
|
|
|
|
```bash
|
|
grep -rn "fun followUser\|class FollowListManager" amethyst/src/main/java/
|
|
```
|
|
|
|
Identify the minimum unit to move. Sometimes it's a whole file,
|
|
sometimes one function. Prefer the smallest unit that makes the
|
|
command possible.
|
|
|
|
### Step 2 — List Android-only dependencies
|
|
|
|
Walk the imports. The usual offenders:
|
|
|
|
| Dependency | Treatment |
|
|
|---|---|
|
|
| `android.content.Context` | Often accidental — inline if only used for logging or preferences. Otherwise, invert as constructor arg. |
|
|
| `android.content.SharedPreferences` | Abstract behind an interface in `commons/`; Android actual uses SharedPreferences, JVM actual uses a JSON file. |
|
|
| `androidx.work.WorkManager` | Rarely shareable — if the CLI needs it, simplify the flow to not require background scheduling. |
|
|
| `android.util.Log` | Replace with `quartz` `PlatformLog` (already multiplatform). |
|
|
| `android.graphics.Bitmap` | Almost never needed by Amy. Keep in Android and split the function. |
|
|
| `android.net.Uri` | Replace with `kotlinx.io` path types or a plain `String`. |
|
|
| `androidx.compose.*` | Must stay out of `commons/commonMain` unless you're in a Compose-Multiplatform module. Amy doesn't depend on Compose. |
|
|
|
|
### Step 3 — Pick a migration strategy per dependency
|
|
|
|
- **Inline-able.** One call, trivial. Delete it.
|
|
- **Platform-abstractable.** Add `expect` in `commons/commonMain/` +
|
|
`actual` in `commons/androidMain/` + `actual` in `commons/jvmMain/`.
|
|
See `kotlin-multiplatform` skill for the mechanics and for the
|
|
`jvmAndroid` source-set pattern used throughout this repo.
|
|
- **Inversion-of-control.** Take the Android dependency as a
|
|
constructor arg with an interface type. Amy supplies a JVM flavour;
|
|
Android supplies the Context-backed one.
|
|
|
|
### Step 4 — Move the code
|
|
|
|
```bash
|
|
# Target location depends on what it is:
|
|
# - Protocol → quartz/src/commonMain/kotlin/…
|
|
# - Business logic → commons/src/commonMain/kotlin/…
|
|
# - UI → commons/src/commonMain/… (needs Compose Multiplatform)
|
|
git mv amethyst/src/main/java/com/.../FollowListManager.kt \
|
|
commons/src/commonMain/kotlin/com/.../FollowListManager.kt
|
|
```
|
|
|
|
Update package declarations. Run `./gradlew spotlessApply`.
|
|
|
|
### Step 5 — Update the Android caller
|
|
|
|
The amethyst/ caller now imports from the new location. Often this
|
|
is the only code change visible in the Android app.
|
|
|
|
If the Android caller was using a concrete Android-backed
|
|
dependency, it now supplies that concrete dependency explicitly.
|
|
|
|
### Step 6 — Add a JVM test
|
|
|
|
In `commons/src/commonTest/kotlin/…` or `commons/src/jvmTest/kotlin/…`
|
|
(depending on what the code exercises), add a test that runs on JVM.
|
|
This guards against Android-only imports sneaking back in, and it's
|
|
the only way to be sure Amy can now call the code.
|
|
|
|
### Step 7 — Commit
|
|
|
|
Single commit, descriptive:
|
|
|
|
> refactor(follow): extract FollowListManager to commons for CLI reuse
|
|
>
|
|
> Move FollowListManager from amethyst/model/nip02FollowLists/ to
|
|
> commons/commonMain/.../followLists/. Android's SharedPreferences
|
|
> dependency is inverted behind FollowListStore (interface); Android
|
|
> keeps the SharedPreferences-backed actual, new JvmFollowListStore
|
|
> writes JSON to disk. No behaviour change on Android.
|
|
|
|
### Step 8 — Now add the CLI command
|
|
|
|
Separate commit. Follows the pattern in `command-template.md`.
|
|
|
|
## Cautionary notes
|
|
|
|
- **Don't extract speculatively.** Only extract what the current
|
|
command needs. A feature-complete port can happen later; right now
|
|
the goal is to unblock one command without adding surface area you
|
|
don't have a second caller for.
|
|
- **Android is allowed to keep side-effects.** Notifications,
|
|
background services, Intents, camera, permissions dialogs — those
|
|
stay in `amethyst/`. Amy's job isn't to replicate UX, it's to
|
|
exercise the protocol underneath.
|
|
- **Check the consumers.** Sometimes the "logic" you want is already
|
|
partially in `commons/`, and the `amethyst/` class is just a thin
|
|
wrapper. In that case, re-use the `commons/` class directly and
|
|
delete the wrapper or keep it if Android genuinely needs it.
|
|
- **Tests first if you're nervous.** Copy the existing
|
|
`amethyst/`-side test (if any), make it JVM-only by removing
|
|
Android imports, and watch it pass after the move.
|
|
|
|
## Red flags during extraction
|
|
|
|
Stop and reconsider if:
|
|
|
|
- The Android class is 1000+ lines. Extract only the piece the CLI
|
|
needs; leave the rest for a follow-up.
|
|
- You need `Context` in 30 places. It's probably being used as a
|
|
grab-bag; sort by actual use (strings, preferences, services, …)
|
|
and abstract those individually.
|
|
- You find yourself writing `expect class` with a dozen methods. A
|
|
fine-grained interface is usually clearer than a monolithic
|
|
expect-actual.
|
|
- You're about to add a Compose import to `cli/`. Stop.
|