Skip to content

feat: a release of this repository #163

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rldyourmnd merged 1 commit into from
Sep 30, 2026
Merged

feat: a release of this repository #163

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions references/opencode-baseline.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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",
Expand Down Expand Up @@ -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(<config file>), \"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(<config file>), \"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": [
Expand Down Expand Up @@ -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"
},
{
Expand Down Expand Up @@ -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": {
Expand Down
Loading