From a8d17792f02dc070d40fdc5a4cb42bf91e458ab8 Mon Sep 17 00:00:00 2001 From: Danil Silantyev Date: Wed, 30 Sep 2026 12:37:39 +0500 Subject: [PATCH] feat: a release of this repository Published at 0.0.86. Propose changes through this repository's issues and pull requests. --- references/opencode-baseline.json | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/references/opencode-baseline.json b/references/opencode-baseline.json index 0d626b7..aa1e63f 100644 --- a/references/opencode-baseline.json +++ b/references/opencode-baseline.json @@ -121,7 +121,7 @@ "OPENCODE_DISABLE_PROJECT_CONFIG", "OPENCODE_DISABLE_SHARE" ], - "verified_at": "2026-09-29T21:25:11+00:00", + "verified_at": "2026-09-30T07:07:53+00:00", "native_surfaces": { "verified_at": "2026-08-31", "config_home": "~/.config/opencode", @@ -192,7 +192,7 @@ "shape": "file", "source": "https://opencode.ai/docs/tui", "evidence": "page", - "note": "keybinds, theme, attention and sounds, deliberately separate from opencode.json, which the same documentation describes as server and runtime behaviour; the setting route stays opencode.json\n\n**Searched in the product's own pinned bytes on 2026-08-29 and not found, which argues nothing either way.** Fixed-string, anchored to this product's configuration home -- the bare leaf name is in every one of these binaries and proves nothing, so only the anchored form counts. An invented path was searched in the same run and was also absent, so the search discriminates.\n\nThis row stays `page` because **a path built by joining a directory to a name at runtime never appears as a literal**, and that is the shape of every remaining one. Moving it off `page` needs the product run against a target and asked what it resolved, not a deeper grep.\n\n**`tui.jsonc` exists, and the earlier paragraph here that denied it measured wrong.** The 1.18.25 check counted fixed strings: `tui.json` appears, `tui.jsonc` does not -- because the binary never spells it. Re-measured 2026-09-28 against the pinned 1.18.33 artifact (`sha256:149a676b\u2026`, the digest this table pins): `ConfigPaths.projectFiles` walks `targets:[`${o}.jsonc`,`${o}.json`]` and `fileInDirectory` returns `[join(dir,`${t}.json`),join(dir,`${t}.jsonc`)]`, which is what the global `tui` load and each `.opencode`-directory load iterate. The JSONC spelling is built by the same template mechanism this note already describes for the directory half -- the search missed it for the reason given one paragraph up. The declined row carries the consequence: both spellings are real, this provider owns one.\n\n**Still `page` after a pass at it on 2026-08-31, and saying so rather than promoting it on a neighbour's evidence.** What was established: the product *writes* this file. A configuration carrying `theme`, `keybinds` or `tui` that has no `tui.json` beside it gets one written at `join(dirname(), \"tui.json\")`, and the config files include the ones in a resource directory -- so a consumer bundle setting a theme can make the product create a file this provider owns. What was **not** established is the read path from a target: it was looked for in the pinned bytes and not found, and a single `debug config` run with `theme` set did not produce the file either, so the migration needs something a read-only command does not reach. Two things absent is not one thing proven." + "note": "keybinds, theme, attention and sounds, deliberately separate from opencode.json, which the same documentation describes as server and runtime behaviour; the setting route stays opencode.json\n\n**Searched in the product's own pinned bytes on 2026-08-29 and not found, which argues nothing either way.** Fixed-string, anchored to this product's configuration home -- the bare leaf name is in every one of these binaries and proves nothing, so only the anchored form counts. An invented path was searched in the same run and was also absent, so the search discriminates.\n\nThis row stays `page` because **a path built by joining a directory to a name at runtime never appears as a literal**, and that is the shape of every remaining one. Moving it off `page` needs the product run against a target and asked what it resolved, not a deeper grep.\n\n**`tui.jsonc` exists, and the earlier paragraph here that denied it measured wrong.** The 1.18.25 check counted fixed strings: `tui.json` appears, `tui.jsonc` does not -- because the binary never spells it. Re-measured 2026-09-28 against the pinned 1.18.33 artifact (`sha256:149a676b…`, the digest this table pins): `ConfigPaths.projectFiles` walks `targets:[`${o}.jsonc`,`${o}.json`]` and `fileInDirectory` returns `[join(dir,`${t}.json`),join(dir,`${t}.jsonc`)]`, which is what the global `tui` load and each `.opencode`-directory load iterate. The JSONC spelling is built by the same template mechanism this note already describes for the directory half -- the search missed it for the reason given one paragraph up. The declined row carries the consequence: both spellings are real, this provider owns one.\n\n**Still `page` after a pass at it on 2026-08-31, and saying so rather than promoting it on a neighbour's evidence.** What was established: the product *writes* this file. A configuration carrying `theme`, `keybinds` or `tui` that has no `tui.json` beside it gets one written at `join(dirname(), \"tui.json\")`, and the config files include the ones in a resource directory -- so a consumer bundle setting a theme can make the product create a file this provider owns. What was **not** established is the read path from a target: it was looked for in the pinned bytes and not found, and a single `debug config` run with `theme` set did not produce the file either, so the migration needs something a read-only command does not reach. Two things absent is not one thing proven." } ], "declined": [ @@ -254,7 +254,7 @@ }, { "path": "managed-config", - "reason": "Not a path in the target, and named without an extension for that reason: the managed configuration directory is a **system** path, one per operating system, and every recorded path here is relative to the target.\n\n * Linux \u2014 `/etc/opencode/`\n * macOS \u2014 `/Library/Application Support/opencode/`\n * Windows \u2014 `%ProgramData%\\\\opencode`\n\nAll three are in the 1.18.25 bundle's own emitted source, in one switch: `case\"darwin\": return \"/Library/Application Support/opencode\"; case\"win32\": return join(process.env.ProgramData||\"C:\\\\ProgramData\",\"opencode\"); default: return \"/etc/opencode\"`. macOS additionally reads a managed plist from the `ai.opencode.managed` preference domain, deployable by MDM, which the same bundle carries as `parseManagedPlist` and `managedPreferences`.\n\n**It bears on the `full-auto` posture**, the same way the managed policy does on the harness next door. An administrator's `opencode.json` there is loaded at the highest priority tier and overrides everything, so this provider can install, verify and restore a permissive posture cleanly on a managed machine and change nothing about what the product actually permits. The setup is not wrong and the target is not wrong; a higher layer wins.\n\nRecorded and never touched: it needs root or Administrator to write, it is not under the configuration home this provider is given, and a provider that edited an organisation's policy would be doing the one thing this estate refuses everywhere else.\n\nThe user configuration home is **not** per-OS, which is why only this row is. The same bundle resolves it as `XDG_CONFIG_HOME || ~/.config` joined with the application name, with no platform branch at all.", + "reason": "Not a path in the target, and named without an extension for that reason: the managed configuration directory is a **system** path, one per operating system, and every recorded path here is relative to the target.\n\n * Linux — `/etc/opencode/`\n * macOS — `/Library/Application Support/opencode/`\n * Windows — `%ProgramData%\\\\opencode`\n\nAll three are in the 1.18.25 bundle's own emitted source, in one switch: `case\"darwin\": return \"/Library/Application Support/opencode\"; case\"win32\": return join(process.env.ProgramData||\"C:\\\\ProgramData\",\"opencode\"); default: return \"/etc/opencode\"`. macOS additionally reads a managed plist from the `ai.opencode.managed` preference domain, deployable by MDM, which the same bundle carries as `parseManagedPlist` and `managedPreferences`.\n\n**It bears on the `full-auto` posture**, the same way the managed policy does on the harness next door. An administrator's `opencode.json` there is loaded at the highest priority tier and overrides everything, so this provider can install, verify and restore a permissive posture cleanly on a managed machine and change nothing about what the product actually permits. The setup is not wrong and the target is not wrong; a higher layer wins.\n\nRecorded and never touched: it needs root or Administrator to write, it is not under the configuration home this provider is given, and a provider that edited an organisation's policy would be doing the one thing this estate refuses everywhere else.\n\nThe user configuration home is **not** per-OS, which is why only this row is. The same bundle resolves it as `XDG_CONFIG_HOME || ~/.config` joined with the application name, with no platform branch at all.", "source": "https://opencode.ai/docs/config; measured in the 1.18.25 bundle, whose bytes match this baseline's own sha256" }, { @@ -354,7 +354,7 @@ } }, "version": "1.18.33", - "verified_at": "2026-09-29T21:25:11+00:00" + "verified_at": "2026-09-30T07:07:53+00:00" }, "setup_catalogue_digest": "sha256:7af5d88d0f5d51510d0b496fa95e84cc27b308be0fdbd3e3a1efca30eaac7e2c", "previous_software_artifacts": {