feat(extension): build provenance stamping for verifiable binaries by gennadiryan · Pull Request #292 · harmoniqs/amicode

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

gennadiryan · 2026-08-08T03:51:39Z

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

What changed

The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

The stamp is written at build time only; runtime reads of it never re-derive the values.
Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

No change to the fork's behavior or to the webview runtime.
The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.

…opencode.lock): pin to v1.18.10-amicode.4 (#245)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db, unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can therefore boot a HEALTHY server on a FRESH database: panels show an empty history while the real one sits untouched on disk (fleet incident 2026-08-08, diagnosed by hand over hours). Two cheap, never-blocking additions to ServerManager: - log the spawned binary's sha256 at start (provenance for post-mortems, complements #292) - warnIfServingFreshDb: after health, if /session serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING to the output channel and toast with an 'Open Output' action False-positive analysis: fresh installs have no large sibling DB (silent); a fork serving its own large DB serves a high session count (silent); the client-tunnel path serves the canonical count through the tunnel (silent). Any probe failure is silent by construction.

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Gennadi Ryan added 3 commits August 7, 2026 07:49

feat(extension): bug-session orchestration + lifecycle (#251), chore(…
2028412
…opencode.lock): pin to v1.18.10-amicode.4 (#245)

Adding provenance stamping to catch bad build configurations
98b7cff

fix(extension): attribute detached builds in the provenance stamp
4860c95

jeonghun-jj-lee merged commit 0944b3b into mainAug 8, 2026
6 checks passed

jeonghun-jj-lee deleted the dev/gennadiryan/provenance-fix branch August 8, 2026 06:12

aarontrowbridge mentioned this pull request Aug 8, 2026
feat(extension): channel-flip guard for the chat session DB #295
Draft

Uh oh!

Conversation

gennadiryan commented Aug 8, 2026

Problem

Approach

Approaches Considered

Scope

What changed

Verification

Key Decisions

Constraints & Invariants

Source

Notes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

gennadiryan commented Aug 8, 2026

Problem

Approach

Approaches Considered

Scope

What changed

Verification

Key Decisions

Constraints & Invariants

Source

Notes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

gennadiryan commented Aug 8, 2026

Problem

Approach

Approaches Considered

Scope

What changed

Verification

Key Decisions

Constraints & Invariants

Source

Notes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

gennadiryan commented Aug 8, 2026

Problem

Approach

Approaches Considered

Scope

What changed

Verification

Key Decisions

Constraints & Invariants