opencode-plugin-flow 6.9.0 → 7.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (5) hide show
  1. package/CHANGELOG.md +80 -0
  2. package/README.md +92 -205
  3. package/dist/index.js +108 -95
  4. package/dist/index.js.map +20 -18
  5. package/package.json +5 -5
package/CHANGELOG.md CHANGED
@@ -6,6 +6,86 @@ One short entry per release, written for users deciding whether to upgrade.
6
6
 
7
7
  No changes yet.
8
8
 
9
+ ## [7.0.1] - 2026-07-27
10
+
11
+ Dependency currency, with one bump that changes what is actually tested:
12
+
13
+ - The pinned OpenCode host moves from 1.18.3 to 1.18.6. Flow's peer range has
14
+ always admitted it (`>=1.18.3 <2`), so anyone running a 1.18.4-1.18.6 host was
15
+ installing against a version no check here had launched. That pin is also the
16
+ host `bun run smoke:live` starts, so 7.0.1 is the first release whose live
17
+ smoke ran on 1.18.6.
18
+ - Build-time only: `@biomejs/biome` 2.5.5, `@types/node` 26.1.1 (with the
19
+ repo-wide `overrides` entry moved with it), and `actions/checkout` v7.0.1
20
+ across all seven pinned workflow references. None of these reach the published
21
+ package.
22
+ - `.github/dependabot.yml` referred maintainers to compatibility checks
23
+ "described in docs/development.md" that were never written there. They are now,
24
+ including why the peer range must not admit a host no check has launched.
25
+
26
+ No runtime source changed. The Session v5 schema, every durable document, and
27
+ Flow's behaviour are identical to 7.0.0; upgrade only if you run an OpenCode
28
+ host newer than 1.18.3 and would rather it be one Flow has been smoke-tested
29
+ against.
30
+
31
+ Install or update:
32
+
33
+ ```bash
34
+ opencode plugin opencode-plugin-flow@7.0.1 --global --force
35
+ ```
36
+
37
+ ## [7.0.0] - 2026-07-27
38
+
39
+ A `broad` validation claim now has to be one, and the two review-finding fields
40
+ 6.9.0 introduced are reachable for the first time:
41
+
42
+ - **Breaking.** A command recorded at `broad` scope is refused when it selects
43
+ which tests it runs, either by naming a test file or by filtering with `-t`,
44
+ `--test-name-pattern`, `--testNamePattern`, `-k`, `-run`, `--grep` or
45
+ `--filter`. 6.9.0 accepted all of these. A repository whose canonical gate is a
46
+ filtered command must record that command as `focused` and arm the whole suite
47
+ for the broad observation a final review requires.
48
+ - **Breaking.** A failing broad observation now blocks its own feature's review
49
+ until that exact command passes again for the current workspace content.
50
+ Previously a red repository gate was discharged by arming something smaller
51
+ under the same label: every field of the resulting record true, and the gate
52
+ itself never passing.
53
+ - `reviewFinding` in the host tool schema was `.strict()` without `scopeBlocker`
54
+ or `findingId`, so every submission the review skill instructs was rejected at
55
+ the boundary even though the durable schema accepts both and `nextAction`
56
+ already reads `scopeBlocker`. Both fields now pass, with a parity test holding
57
+ the host schema to the durable one.
58
+ - An explicit grant of authority over already-planned work reads as continuation
59
+ rather than a goal change. A session planned with "do not implement anything
60
+ yet" and then told "you have my approval to implement it end to end" no longer
61
+ refuses the authorization it was just given. New or different outcomes are
62
+ still refused.
63
+ - Three architecture gates make the layering enforceable rather than described:
64
+ every `src` export must be imported outside its declaring file, every
65
+ `@opencode-ai/*` import must route through `src/platform/opencode/sdk.ts`, and
66
+ the source and documentation budgets report their remaining headroom instead of
67
+ speaking up only once they are exceeded.
68
+
69
+ The durable-invariant checker moved out of `transitions.ts` into
70
+ `src/domain/session-invariants.ts`, with its rule families explained and eleven
71
+ tests covering them; it previously had no direct coverage at all. The README is
72
+ half its former size. ADR 0009 now records what the model-driven harness measured
73
+ rather than what its guards were expected to do, including one escape left
74
+ deliberately open: a `broad` command that cannot fail, such as `git diff --check`,
75
+ is still accepted, because refusing it means deciding which commands count as
76
+ tests.
77
+
78
+ The Session v5 schema is unchanged, and no durable document written by a 6.x
79
+ build is rejected on load. Both refusals above apply when new evidence is
80
+ recorded, so a session carrying a filtered broad observation from 6.9.0 keeps it
81
+ and needs a whole-suite pass before its final review.
82
+
83
+ Install or update:
84
+
85
+ ```bash
86
+ opencode plugin opencode-plugin-flow@7.0.0 --global --force
87
+ ```
88
+
9
89
  ## [6.9.0] - 2026-07-26
10
90
 
11
91
  Rules the prompts used to restate are now enforced by the runtime, and Flow no
package/README.md CHANGED
@@ -1,266 +1,154 @@
1
1
  # Flow Plugin for OpenCode
2
2
 
3
- `opencode-plugin-flow` gives OpenCode a small, durable workflow for coding work
4
- that benefits from an approved plan and an independent review:
3
+ `opencode-plugin-flow` gives OpenCode a durable workflow for coding work that
4
+ benefits from an approved plan and an independent review:
5
5
 
6
6
  ```text
7
7
  plan → approve → run one feature → validate → review → repeat or close
8
8
  ```
9
9
 
10
- Flow keeps one durable active feature run at a time. When implementation divides
11
- cleanly, the manager may ask a small host-native worker cohort to contribute in
12
- parallel before it validates and reviews the combined result.
10
+ Flow keeps one durable active feature run at a time. Once a session starts it
11
+ stays the workflow for that goal until Flow records completed, deferred, or
12
+ abandoned closure. It never silently falls back to ordinary coding, and it does
13
+ not fold a materially different request into the active goal.
13
14
 
14
- Once a Flow session starts, it remains the workflow for that goal until Flow
15
- records completed, deferred, or abandoned closure. It never silently falls back
16
- to ordinary non-Flow coding, and it does not fold a materially different request
17
- into the active goal.
15
+ State lives in `.flow/session.json`, so the workflow survives a restart, a
16
+ context change, or a lost transcript.
18
17
 
19
18
  ## Install
20
19
 
21
20
  Install the exact npm release through OpenCode:
22
21
 
23
22
  ```bash
24
- opencode plugin opencode-plugin-flow@6.9.0 --global --force
23
+ opencode plugin opencode-plugin-flow@7.0.1 --global --force
25
24
  ```
26
25
 
27
- Omit `--global` for project scope. Exact version pins do not update
28
- automatically. To update, replace `6.9.0` with the new release and rerun the
29
- command.
30
-
31
- Before upgrading from Flow v5 or earlier, finish or explicitly close any active
32
- session with its original Flow version. Flow v6 opens only Session v5 active
33
- state; older archives remain inert history.
34
-
35
- Do not roll an active session back to an older Flow build after a newer build
36
- has written it. Newer v6 builds read earlier Session v5 state, but Session v5 is
37
- not a promise that older readers understand later widened safety bounds. Finish
38
- or close the active session before downgrading; Flow adds no capability or
39
- migration layer for rollback.
26
+ Omit `--global` for project scope. Version pins are exact and never update on
27
+ their own; to update, rerun the command with the new version.
40
28
 
41
29
  The equivalent manual project configuration is:
42
30
 
43
31
  ```json
44
32
  {
45
33
  "$schema": "https://opencode.ai/config.json",
46
- "plugin": ["opencode-plugin-flow@6.9.0"]
34
+ "plugin": ["opencode-plugin-flow@7.0.1"]
47
35
  }
48
36
  ```
49
37
 
50
- Restart OpenCode after changing configuration. OpenCode owns package
51
- installation and configuration; see its
38
+ Restart OpenCode after changing configuration. OpenCode owns installation and
39
+ configuration; see its
52
40
  [plugin documentation](https://opencode.ai/docs/plugins/). Flow has no installer
53
- or activation CLI. Removing the plugin entry disables it. If two Flow copies
41
+ or activation CLI, and removing the plugin entry disables it. If two Flow copies
54
42
  load for one project, both fail closed until the duplicate is removed.
55
43
 
56
- ## Quick start
44
+ **Changing versions.** Finish or explicitly close any active session first, in
45
+ either direction. Flow v6 opens only Session v5 active state, and an older build
46
+ cannot be trusted to read state a newer one has already written. Older archives
47
+ remain inert history, and there is no migration or rollback layer.
57
48
 
58
- Start a complete workflow:
49
+ ## Quick start
59
50
 
60
51
  ```text
61
52
  /flow-auto add rate limiting to the public API
62
53
  ```
63
54
 
64
- Flow inspects the worktree, proposes a feature plan, and asks for approval
65
- unless your request already authorized implementation. It then runs one
66
- runnable feature at a time, validates the actual workspace, obtains an
67
- independent review, and repeats until it can close the session. While
68
- implementation remains authorized, `ready` and `completed` are internal loop
69
- states: `/flow-auto` does not hand back “ready for the next feature” or wait for
70
- another command between passing features. From idle, auto-routing first requires
71
- a same-host accepted non-replayed `flow_plan_save` for the created Flow session;
72
- an active baseline that already has a pending reviewer retains a narrow temporal
73
- exception for that completion.
55
+ `/flow-auto` is the ordinary end-to-end driver. It inspects the worktree,
56
+ proposes a feature plan, and asks for approval unless your request already
57
+ authorized implementation. It then runs one feature at a time — implement,
58
+ validate against the real workspace, obtain an independent review — and keeps
59
+ going through every runnable feature without handing back between them, until it
60
+ can close the session.
74
61
 
75
62
  Send `/flow-auto stop` or `/flow-auto cancel` in the same OpenCode session to
76
- revoke only the process-local continuation lease. This does not close, defer,
77
- abandon, or otherwise mutate the durable Flow session.
78
-
79
- Before every manager-owned Flow mutation, including direct `/flow-plan` and
80
- `/flow-run` use, the manager compares the current request with the active goal.
81
- A projected `archiveRetry` is the one exception: it finishes an already-accepted
82
- close before that comparison and grants no authority for new work.
83
- A continuation or compatible narrowing may proceed. A materially new or
84
- expanded request does not start or mutate the active session; Flow offers to
85
- continue, defer, or abandon the active work. If that work is completed but not
86
- closed, Flow closes it as completed before starting the new request.
87
-
88
- Existing implementation authority carries across approval and feature outcomes.
89
- Flow automatically resets and atomically starts one fresh full retry only when
90
- the projected `nextAction` is `flow_feature_reset`, which the runtime derives
91
- from `failedReviewCount` and `blockedFeature.scopeBlocker`. A
92
- feature whose latest relevant reviewed outcome remains failed is never selected
93
- implicitly. `/flow-auto` may continue untouched, dependency-independent
94
- features, but when only retry-required candidates remain it projects
95
- `await-user-direction`. Flow then reports the blocker and waits for an explicit
96
- retry or independent-feature choice. While the failed run is still blocked, the
97
- chosen feature is attached to `flow_feature_reset` as `nextFeatureId`, so reset
98
- and the next run are one operation. If independent work later finishes and only
99
- the superseded failed feature remains, status is ready with
100
- `await-user-direction`; explicit retry then uses `flow_run_start` with that
101
- feature's exact `featureId`, because there is no blocked run left to reset. The
102
- active session remains authoritative while it waits. Ordinary blocking findings
103
- are in-scope by default; a reviewer sets `scopeBlocker: true` on a finding only
104
- when the required repair would materially exceed the approved plan. Each finding
105
- also carries a runtime-issued `findingId`, and a failed result must carry every
106
- still-live prior ID forward, which `flow_feature_complete` enforces. After a user checkpoint, the
107
- process-local continuation resumes only after that same OpenCode session observes
108
- an accepted non-replayed Flow mutation whose tool assistant ID resolves, through
109
- the cached `message.updated` `parentID`, to the authoritative user reply. A
110
- missing or mismatched origin fails closed. Another host cannot establish that
111
- authority. The mechanical projection must match the credited revision exactly;
112
- the sole successor allowance is one revision after an authenticated
113
- `flow_review_start`, where the state machine admits the reserved reviewer result.
114
- Compaction transfers the reply authority only across an authenticated trigger
115
- assistant, automatic compaction marker, summary assistant, and successor user
116
- lineage while the authority is unchanged; an incomplete or unrelated lineage
117
- fails closed.
118
-
119
- Before coding each feature, Flow inventories required evidence and its
120
- environment, then applies an adversarial risk checklist covering failure
121
- ordering, repeated and interrupted operations, adjacent state transitions,
122
- overlapping invariants, and relevant file-mode or platform risks. While required
123
- behavior or environment evidence is knowingly skipped, manager policy forbids
124
- requesting review; the reviewer treats proof required to approve the outcome as
125
- blocking if it is missing from the packet. Flow persists no skipped-evidence
126
- ledger. Asking the user remains the default when external evidence or authority
127
- is missing. At a blocked checkpoint, atomic reset-and-start can discard that
128
- attempt and continue the
129
- exact authorized retry or dependency-independent feature. At a ready retry
130
- checkpoint, explicit feature start resumes the already superseded failure.
131
- Neither route adds a hold or second blocker ledger.
132
-
133
- Flow guidance represents the checklist for concurrency and state-machine work
134
- as one compact transition matrix shared by workers and the reviewer. Review
135
- packets reuse a refreshed run baseline, carry only feature-relevant file facts
136
- until final review, and preserve source IDs, current-source evidence, risk
137
- coverage, and prior finding dispositions in existing text fields—no new audit
138
- schema.
139
-
140
- For plan-only or advanced use, plan first:
63
+ revoke only the in-process continuation. That does not close, defer, abandon, or
64
+ otherwise change the durable Flow session.
65
+
66
+ Before any Flow mutation, Flow compares your request against the active goal. A
67
+ continuation or a compatible narrowing proceeds. A materially new or expanded
68
+ request does not start or mutate the active session: Flow offers to continue,
69
+ defer, or abandon the active work first, and closes work that is already
70
+ complete before starting something new.
71
+
72
+ To plan without implementing:
141
73
 
142
74
  ```text
143
75
  /flow-plan add rate limiting to the public API
144
76
  ```
145
77
 
146
- Review the proposed plan and approve it conversationally. `/flow-plan` does not
147
- silently grant permission to implement, commit, push, or publish. After
148
- approval of a plan-only request, `/flow-run` can run or recover one feature.
149
- Repeating a same-goal plan-only request after approval reports the immutable plan
150
- and current progress, then stops without rewriting the plan or starting work.
151
-
152
- `/flow-run` and `/flow-status` are advanced/recovery controls. At any point,
153
- `/flow-status` reports the durable state and next action. After `/flow-auto` has
154
- run in the current plugin process, status also reports a non-authoritative timer
155
- for the latest invocation. `activeMs` is process-local wall time classified as
156
- active by the coordinator, not CPU time or pure coding time.
157
- `waitingForUserMs` counts only projected `flow_plan_approve` and
158
- `await-user-direction` checkpoints. Plugin restart resets the timer; paused,
159
- inactive, errored, and unprojected waits are excluded.
78
+ Review the plan and approve it conversationally. `/flow-plan` never grants
79
+ permission to implement, commit, push, or publish. After approval, `/flow-run`
80
+ executes or recovers one approved feature. Repeating the same plan-only request
81
+ reports the immutable plan and current progress instead of rewriting it.
82
+
83
+ `/flow-status` reports durable state and the next action at any point. That next
84
+ action is the default workflow direction, not permission to exceed the authority
85
+ you granted.
160
86
 
161
87
  ## How Flow works
162
88
 
163
89
  1. Planning saves a small feature DAG. Approval locks it.
164
- 2. `/flow-run` starts one feature whose dependencies are complete.
165
- 3. Before editing, the manager preflights required evidence and gives any
166
- bounded workers an explicit adversarial acceptance and risk checklist.
167
- 4. The manager implements it serially or integrates an optional bounded worker
168
- wave.
90
+ 2. One feature starts, chosen only from those whose dependencies are complete.
91
+ 3. Before editing, the manager gathers the evidence the feature needs and works
92
+ through an adversarial risk checklist: failure ordering, repeated and
93
+ interrupted operations, adjacent state transitions, overlapping invariants,
94
+ and file-mode or platform risk.
95
+ 4. The manager implements the feature, serially or by integrating a bounded
96
+ worker wave.
169
97
  5. Flow observes the exact armed validation command against the current
170
- workspace, then creates one independent review assignment. At new review
171
- admission, a relevant failure or source-drift observation invalidates older
172
- passes; the qualifying pass must be newer and match current source. Separately,
173
- the manager must not call `flow_review_start` while known required behavior or
174
- environment evidence is skipped; this is workflow policy, not persisted
175
- admission state. Already accepted Session v5 pending or completed reviews are
176
- not reopened or vetoed later at close.
177
- 6. The reviewer inspects adjacent and repeated state transitions, overlapping
178
- feature invariants, the changed artifacts, and the packet's base-diff and
179
- file-mode inventory. Stable finding IDs survive retries; reviewer guidance
180
- requires checking prior dispositions and completing the supplied risk
181
- checklist, represented as a bounded matrix when applicable. Missing proof is
182
- a precise blocker only when it is required to approve the outcome.
183
- 7. A passing feature advances the plan. A failed feature is not selected again
184
- by default. From blocked status, reset atomically starts the exact authorized
185
- retry or independent feature through optional `nextFeatureId`. From ready
186
- `await-user-direction`, the failed run is already superseded and explicit
187
- `flow_run_start(featureId)` begins its retry. The final passing feature allows
188
- explicit closure. Every accepted close returns a concise delivery summary
189
- with each feature's attempt count, latest outcome, and terminal findings,
190
- derived from Flow's recorded state. Ordinary reviewer summaries carry IDs
191
- mapped to the active feature or explicitly supplied in its packet; final
192
- review carries every approved requirement or feature ID. Both carry each
193
- still-live prior finding with its severity and disposition into the latest
194
- `outcomeSummary`. Terminal
195
- `fixed` requires a later passing review and current evidence. If a failed
196
- retry proves one repair but finds another blocker, it carries that ID and a
197
- concise evidence reference forward as terminal fixed pending pass; it cannot
198
- drop the ID or call it fixed. Unproven fixes stay unverified, `recurring`
199
- confirms recurrence, and `residual` requires a confirmed nonblocker. Only a
200
- passing review may remove fixed history from the live carry-forward set.
201
- Terminal findings retain unresolved blockers and the handoff stays bounded.
202
-
203
- State lives in `.flow/session.json`, so `/flow-status` can recover the next
204
- action after a restart or context change.
98
+ workspace, then opens one independent review assignment. A newer relevant
99
+ failure or a source change invalidates an older pass, and review cannot be
100
+ requested while evidence the outcome depends on is knowingly missing.
101
+ 6. A passing review advances the plan. A failed feature is never picked up again
102
+ implicitly — Flow reports the blocker and waits for an explicit retry or an
103
+ independent-feature choice. The last passing feature allows closure, and every
104
+ accepted close returns a delivery summary derived from recorded state: each
105
+ feature's attempts, latest outcome, and terminal findings.
106
+
107
+ Findings keep stable ids across retries, and a failed review must carry every
108
+ still-live finding forward — the runtime rejects a submission that drops one. A
109
+ reviewer marks a finding as out of scope only when the repair would materially
110
+ exceed the approved plan.
205
111
 
206
112
  ## Bounded parallelism
207
113
 
208
- Parallel contribution is optional and local to one active feature. The manager
209
- may launch two or three `flow-worker` instances only for exact,
210
- non-overlapping slices, then inspect and integrate their work. At most one
211
- targeted follow-up wave may address a concrete gap. Once implementation is
212
- authorized, a qualifying wave needs no separate approval.
114
+ Parallel work is optional and confined to one active feature. The manager may
115
+ launch two or three `flow-worker` instances for exact, non-overlapping slices,
116
+ then inspect and integrate the result, with at most one follow-up wave for a
117
+ concrete gap. Once implementation is authorized, a qualifying wave needs no
118
+ separate approval.
213
119
 
214
- Workers cannot delegate, call Flow lifecycle tools, or approve their own work.
215
- Generic or general-purpose agents are not used for active Flow work: bounded
216
- implementation uses `flow-worker`, and independent review uses
217
- `flow-reviewer`.
218
- Flow persists no wave state: the manager remains responsible for the combined
219
- diff, authoritative validation, and the one independent review. Small or
220
- integration-heavy tasks stay serial.
120
+ Workers cannot delegate, call Flow lifecycle tools, or approve their own work,
121
+ and general-purpose agents are never used for active Flow work: implementation
122
+ uses `flow-worker`, independent review uses `flow-reviewer`. Flow persists no
123
+ wave state, so the manager stays responsible for the combined diff, the
124
+ authoritative validation, and the one independent review. Small or
125
+ integration-heavy features stay serial.
221
126
 
222
127
  ## Commands
223
128
 
224
129
  | Command | Purpose |
225
130
  | --- | --- |
226
- | `/flow-auto <goal>` | Normal end-to-end driver; it stops after planning without implementation authority, otherwise loops through every runnable feature and closure without an intermediate handoff. |
227
- | `/flow-plan <goal>` | Plan-only/advanced creation, revision, and approval. |
131
+ | `/flow-auto <goal>` | Normal end-to-end driver. Stops after planning without implementation authority; otherwise loops through every runnable feature and closure. |
132
+ | `/flow-plan <goal>` | Plan-only creation, revision, and approval. |
228
133
  | `/flow-run` | Advanced/recovery execution of one approved feature. |
229
134
  | `/flow-review` | Internal/recovery dispatch for a runtime-created reviewer assignment. |
230
135
  | `/flow-status` | Advanced/recovery inspection of the active session and next action. |
231
136
 
232
- Use `/flow-auto` for the ordinary end-to-end workflow. The other commands expose
233
- plan-only, advanced, internal, or recovery controls.
137
+ Use `/flow-auto` for ordinary work. The rest expose plan-only, advanced,
138
+ internal, or recovery controls.
234
139
 
235
140
  ## Recovery
236
141
 
237
- Start with `/flow-status`; its next action is durable default workflow
238
- direction, not permission to exceed the user's authority. For a first failed
239
- review, read detail once before reset to see the findings the retry must fix.
240
- Pass the exact retry or dependency-independent choice as
241
- `nextFeatureId` so reset and run start are atomic; do not reset and then rely on
242
- default selection. If status is ready with `await-user-direction`, read detail
243
- once and pass the explicitly authorized retry's exact `featureId` to
244
- `flow_run_start`; reset is invalid because the failed run was already
245
- superseded. Environment-sensitive transition guards remain authoritative when a
246
- mutation is attempted. Do not hand-edit
247
- `.flow/session.json` to bypass a gate. If validation, review, locking,
248
- fingerprinting, or archive publication fails, follow the focused steps in
249
- [troubleshooting](docs/troubleshooting.md).
250
-
251
- For an interrupted accepted close, compact `/flow-status` supplies
252
- `archiveRetry.request`. Replay that request exactly once before any additional
253
- or detail recovery read. Flow confirms the existing bytes without rewriting
254
- Session v5, re-confirms archive cleanup, and returns the existing concise
255
- `workflowData.delivery`. Relay its `report` lines verbatim, and reconstruct only
256
- the plan-bounded, terminal disposition
257
- map from its latest `outcomeSummary` and terminal findings. If delivery is absent,
258
- report the exact recovery and claim no map. On a close revision conflict,
259
- refresh compact status and retry only after confirming the same session and goal
260
- and that status still permits the selected
261
- closure kind; never close a replacement. A real archive collision removes the
262
- automatic retry instruction and requires manual inspection; preserve both
263
- documents and do not overwrite, delete, or loop the request.
142
+ Start with `/flow-status`. After a failed review, read detail once to see the
143
+ findings a retry must fix, then pass the exact retry or independent-feature
144
+ choice so that reset and the next run are one operation rather than relying on
145
+ default selection.
146
+
147
+ If an accepted close was interrupted, compact status supplies
148
+ `archiveRetry.request`; replay it exactly once, before any other recovery read.
149
+ Never close a replacement session, and never hand-edit `.flow/session.json` to
150
+ get past a gate. For a validation, review, locking, fingerprinting, or archive
151
+ failure, follow [troubleshooting](docs/troubleshooting.md).
264
152
 
265
153
  ## Development
266
154
 
@@ -272,11 +160,10 @@ bun install --frozen-lockfile
272
160
  bun run check
273
161
  ```
274
162
 
275
- The normal check runs typechecking, formatting/lint checks, build verification,
276
- tests, and package smoke. Release CI also exercises the packed plugin in a real
277
- OpenCode host.
163
+ `bun run check` runs typechecking, lint, build verification, tests, and package
164
+ smoke. Release CI also exercises the packed plugin in a real OpenCode host.
278
165
 
279
- Maintained documentation starts at [docs/index.md](docs/index.md). See
166
+ Maintained documentation starts at [docs/index.md](docs/index.md):
280
167
  [development](docs/development.md) for repository structure,
281
168
  [troubleshooting](docs/troubleshooting.md) for recovery,
282
169
  [the maintainer contract](docs/maintainer-contract.md) for tools and runtime