Baseline traceability: fork source and verification record
The kernel forks from OpenCode (MIT). This page locks the upstream commit taken at fork time; the kernel does not track upstream afterwards, so security fixes and kernel evolution must be followed deliberately.
| Field | Value |
|---|---|
| Upstream repository | sst/opencode (path at lock time; now moved to anomalyco/opencode) |
| Upstream branch | dev |
| Locked commit | 9c1c061b84cfc4b132faa9dc2e0de3a1e34d87dc |
| Commit message | fix(lsp): remove CMakeLists.txt and Makefile from clangd root markers (#21466) |
| Lock time | 2026-08-22 |
| License | MIT |
| Imported into | agent-forge-runtime |
Upstream keeps moving; the table answers the settled question of which commit we are based on.
In enterprise delivery, version questions usually reduce to three: which commit the base sits on, whether a failure bisects to an upstream change or a local one, and whether the runtime path loads unauthorized commercial code. The baseline pins those to a commit, file hashes, and a load boundary.
Why freeze a commit
Section titled “Why freeze a commit”The kernel is frozen to one commit rather than rolling with an active upstream branch:
- Reproducibility: the file set at a given commit is stable; an active branch changes continuously and cannot serve as a review anchor.
- Blame boundary: when something breaks, you can tell whether the change sits on top of the baseline or outside it.
- Supply-chain review: regulated environments need a clear source and an exact version for the base.
The cost is that security fixes and kernel evolution must be followed deliberately instead of drifting by default.
Granularity: a commit, not a version number
Section titled “Granularity: a commit, not a version number”BASELINE.md records the anchors in the table above. The granularity is a commit: major versions still move internally; a commit does not. That is what makes “inside or outside the baseline” answerable during review.
Hash: checking file identity
Section titled “Hash: checking file identity”Verification requires critical files to match baseline hashes. Matching hashes can be compared mechanically; “looks the same” cannot tell a single-byte difference apart. Any later question of whether kernel files changed uses the same hash criteria.
Verification record
Section titled “Verification record”| Check | Result | Notes |
|---|---|---|
| File consistency | Pass | Critical file hashes match the baseline |
bun install | Conditional pass | See environment pitfall below |
typecheck | 0 errors | Includes baseline SDK artifact fixes |
build | Pass | Single-target build + smoke |
| Identity-bound instance routing | Pass | Authenticated username forwarded to instance routing |
Reproducible install and build example on Windows:
bun install --ignore-scriptsbun run --cwd packages/opencode script/build.ts --single --skip-embed-web-uipackages/opencode in that command is the kernel package directory inside the repository, kept alongside the upstream baseline; the public executable name and config prefixes use agent-forge naming.
The first real pitfall
Section titled “The first real pitfall”A full bun install can fail on Windows: the native dependency tree-sitter-powershell needs the Windows SDK. Passing --ignore-scripts skips that build script and lets install continue. This is an environment limit, not a product logic defect; it does not affect Linux or production image builds, but it blocks a first-time Windows clone.
Boundary between core and enterprise
Section titled “Boundary between core and enterprise”| Scope | Contents |
|---|---|
| Kernel baseline | Aligned to the locked commit above |
| Governance and enterprise capability | Governance modules + enterprise implementation tree |
Design constraint: the MIT core never statically loads enterprise implementations. Enterprise code mounts through two seams:
- Endpoint shell: org writes, audit verify/rehash, and similar paths check license features first; missing key or feature →
403, and enterprise code is not loaded; when authorized → dynamic load. - Predicate: approving tickets started by someone else requires the HITL feature; self-confirmation stays in the open-source core.
flowchart TD Req[Commercial capability request] --> Lic{License has feature?} Lic -->|No| Deny[403, do not load] Lic -->|Yes| Dyn[Dynamically load enterprise impl]Without a license, enterprise code is never loaded or executed. The runtime path is auditable on its own, without relying on license text. Details: Open-Core seam.
Related: