The inert stub written when hook consent is not granted was
`export default async () => ({})`. OpenCode v2 validates every plugin
module before running it and requires the default export to be a definition
object with an `id` and an `effect` or `setup` function, so a declined or
runtime-less home install printed the same startup error as the V1 hook
plugin:
PluginModule.LoadError: Plugin must export a default definition with an id
and an effect or setup function.
(cause: SchemaError(Expected object at ["default"]))
Write `export default { id: "ecc-hooks", setup() {} }` instead. It keeps the
inert behaviour (no imports, no module initialization of the replaced
plugin) and satisfies the loader.
Tests that pinned the generated bytes now compare against
getDisabledOpenCodePluginContent() rather than a duplicated literal, and
tests/opencode-plugin-loader-contract.test.js asserts the loader contract on
the generated payload. That test fails on the previous stub
("default export must be an object, got function").
Refs #3537. The same assertion should cover .opencode/plugins/*.ts once a V2
entrypoint lands (#3536, #3224); those plugins are scanned independently in
home installs, so both the barrel and the implementation are loaded.
Address review findings on #3590:
- Unterminated block comments now throw instead of silently passing:
{'plugin':[]} /* no longer parses, so the install keeps its
source-context error for genuinely malformed configs (CodeRabbit,
Greptile).
- Line-comment scanners stop at CR as well as LF, so CR-only line
endings do not consume the rest of the file (CodeRabbit).
- activationIsInactive restores the 'plugin must be an array' shape
check that the strict parser surfaced, so a non-array plugin no
longer counts as inactive (Greptile).
Regression tests: unterminated comment with source context, CR-only
endings, and non-array plugin across apply/repair/doctor modes.
The read-only plugin-membership check in activationIsInactive and the
validation inside disableOpenCodeHookPluginRegistration used strict
JSON.parse, so any user whose ~/.config/opencode/opencode.json contains
JSONC comments (which OpenCode itself accepts) could not install the
OpenCode catalog. The plan never writes the user-owned config; this
parse is purely a membership read (issue #3546).
Add a string-aware JSONC parser (line/block comments, the trailing
commas they hide, URL strings untouched) and route both call sites
through it. Truly malformed JSON keeps its source-context error.
Tests: unit coverage for comment/trailing-comma/URL handling, plus an
apply-level regression test that installs over an inactive JSONC user
config byte-for-byte, across default and declined consent modes.
Preserve contributor history and current-main behavior while resolving the exact reviewed follow-up.
Source-PR: https://github.com/affaan-m/ECC/pull/3008
Source-Parent: d0dc1fcb08
Review-Manifest-SHA256: 8f15febd33dfa9f9ac6e70cb41f75ffee7aca47dd21782e841c33d4874341d6e
Preserve the contributor change and current installer contracts. Make automatically discovered plugin entrypoints inert without explicit runtime consent, verify managed ownership before deactivation, and retain prior consent on incomplete migration.
Source-PR: https://github.com/affaan-m/ECC/pull/3008
Source-Head: f8c0c2c182
The guided installer asks how ECC hooks should run, but that consent
lived only in the wizard path. Running install-apply directly with a
profile that includes hooks-runtime still materialized the hook runtime
with no disclosure and no decision.
Gate the apply layer instead, so every entry point is covered:
- disclose the six hook capability groups when a plan would materialize
the hook runtime, and refuse to apply until the caller decides
- --enable-hooks confirms the hook runtime; --no-hooks installs the rest
of the selection without it and records the reduced module closure in
install-state
- surface the pending decision as a dry-run warning
- show the same capability disclosure in the guided installer's plan
preview, so the wizard's hook question states what it is asking about
Plans that never materialize hooks (Kimi, --profile minimal,
--without baseline:hooks) are unaffected and need no flag. Repair and
uninstall operate on already-recorded state and stay unchanged.
The capability taxonomy and the held-materialization behavior come from
Samarjeet Singh Tomar's PR #2634, reworked to fit the single-decision
consent model that shipped with the guided installer in #2649.
Co-Authored-By: Samarjeet Singh Tomar <samar_tomar@hotmail.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ali Arslan