mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-09-09 17:16:19 -07:00
docs: refresh user-facing guides and examples
- Clarify current integration, media review, and Anki behavior - Remove obsolete AI translation and configuration references - Standardize headings and prose across docs
This commit is contained in:
+11
-11
@@ -1,10 +1,10 @@
|
||||
# IPC + Runtime Contracts
|
||||
# IPC + runtime contracts
|
||||
|
||||
SubMiner's Electron app runs two isolated processes - main and renderer - that can only communicate through IPC channels. This boundary is intentional: the renderer is an untrusted surface (it loads Yomitan, renders user-controlled subtitle text, and runs in a Chromium sandbox), so every message crossing the bridge passes through a validation layer before it can reach domain logic.
|
||||
SubMiner's Electron app runs two isolated processes, main and renderer, and IPC channels are the only way they talk. That boundary is deliberate. The renderer is an untrusted surface: it loads Yomitan, renders subtitle text SubMiner did not write, and runs in a Chromium sandbox. Every message crossing the bridge goes through a validator before any domain code sees it.
|
||||
|
||||
The contract system enforces this by making channel names, payload shapes, and validators co-located and co-evolved. A change to any IPC surface touches the contract, the validator, the preload bridge, and the handler in the same commit - drift between any of those layers is treated as a bug.
|
||||
Channel names, payload shapes, and validators all live together, so they change together. Touching an IPC surface means updating the contract, the validator, the preload bridge, and the handler in one commit. Drift between those four layers is a bug, not a style preference.
|
||||
|
||||
## Message Flow
|
||||
## Message flow
|
||||
|
||||
Renderer-initiated calls (`invoke`) pass through four boundaries before reaching a service. Fire-and-forget messages (`send`) follow the same path but skip the response leg. Malformed payloads are caught at the validator and never reach domain code.
|
||||
|
||||
@@ -36,7 +36,7 @@ flowchart TB
|
||||
style E fill:#ed8796,stroke:#494d64,color:#24273a,stroke-width:1.5px
|
||||
```
|
||||
|
||||
## Runtime Sockets
|
||||
## Runtime sockets
|
||||
|
||||
The renderer↔main bridge above lives *inside* the Electron app. A separate set of OS sockets connects the app to the other runtimes - mpv and the launcher/plugin. These carry no renderer payloads and bypass the contract/validator layer; they are command and property channels between processes.
|
||||
|
||||
@@ -67,7 +67,7 @@ flowchart LR
|
||||
|
||||
How these sockets are established during launch is covered in [Playback Startup Flow](./architecture#playback-startup-flow).
|
||||
|
||||
## Core Surfaces
|
||||
## Core surfaces
|
||||
|
||||
| File | Role |
|
||||
| --- | --- |
|
||||
@@ -79,7 +79,7 @@ How these sockets are established during launch is covered in [Playback Startup
|
||||
| `src/core/services/anki-jimaku-ipc.ts` | Integration-specific IPC boundary for Anki and Jimaku operations. |
|
||||
| `src/main/cli-runtime.ts` | CLI/runtime command boundary. Handles commands that originate from the launcher or mpv plugin rather than the renderer. |
|
||||
|
||||
## Contract Rules
|
||||
## Contract rules
|
||||
|
||||
These rules exist to prevent a class of bugs where the renderer and main process silently disagree about message shapes - which surfaces as undefined fields, swallowed errors, or state corruption.
|
||||
|
||||
@@ -89,13 +89,13 @@ These rules exist to prevent a class of bugs where the renderer and main process
|
||||
- **Keep payloads narrow.** Send only what the handler needs. Avoid passing entire state objects across the bridge - it couples the renderer to internal main-process structure.
|
||||
- **Co-evolve all layers.** When a payload shape changes, update `contracts.ts`, `validators.ts`, `preload.ts`, and the handler in the same commit. Partial updates are treated as bugs.
|
||||
|
||||
## Two Message Patterns
|
||||
## Two message patterns
|
||||
|
||||
**Invoke (request/response):** The renderer calls a typed bridge method and awaits a result. The main process validates the payload, runs the handler, and returns a structured response. Used for operations where the renderer needs a result - lookups, config reads, mining actions.
|
||||
|
||||
**Fire-and-forget (send):** The renderer sends a message with no response. The main process validates and handles it silently. Malformed payloads are dropped. Used for notifications where the renderer doesn't need confirmation - UI state hints, focus events, position updates.
|
||||
|
||||
## Add a New IPC Action
|
||||
## Add a new IPC action
|
||||
|
||||
1. Add the channel constant in `src/shared/ipc/contracts.ts`.
|
||||
2. Add or extend the payload validator in `src/shared/ipc/validators.ts`.
|
||||
@@ -104,7 +104,7 @@ These rules exist to prevent a class of bugs where the renderer and main process
|
||||
5. Add tests for both valid and malformed payload cases in `src/core/services/*`.
|
||||
6. Update renderer tests when behavior or state transitions change.
|
||||
|
||||
## Runtime State Notes
|
||||
## Runtime state notes
|
||||
|
||||
- Prefer runtime/domain composition via `src/main/runtime/composers/*` and `src/main/runtime/domains/*`. IPC handlers should delegate to composers rather than containing orchestration logic.
|
||||
- Route shared mutable state updates through transition helpers in `src/main/state.ts` for migrated domains. Direct mutation from IPC handlers bypasses invariant checks.
|
||||
@@ -116,7 +116,7 @@ These rules exist to prevent a class of bugs where the renderer and main process
|
||||
- **Renderer invoke fails:** Verify the preload bridge method exists and matches the channel constant. Check that the handler is registered and returning (not throwing).
|
||||
- **Contract drift:** When invoke calls return unexpected shapes, compare the shared contract, validator, preload bridge, and main handler signatures side by side. One of them was updated without the others.
|
||||
|
||||
## Related Docs
|
||||
## Related docs
|
||||
|
||||
- [Architecture](/architecture)
|
||||
- [Development](/development)
|
||||
|
||||
Reference in New Issue
Block a user