Skip to content

test: opencode-mem 2.28.3 on stock OpenCode 2.0.22 - #124

Draft
xnoto wants to merge 5 commits into
mainfrom
test/opencode-memory-v2-runtime
Draft

xnoto wants to merge 5 commits into
mainfrom
test/opencode-memory-v2-runtime

Conversation

@xnoto

@xnoto xnoto commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Owner-authorized isolated reassessment of opencode-mem@2.28.3 on the production-selected stock OpenCode 2.0.22 Linux/amd64 image, digest sha256:11f2b6c96d380867387fbee390c06cb47efffd9fdc37009b4cd40795b45dad19. Adapt the established synthetic CI pattern without changing historical #113 or reviving closed init/custom-image experiments.

Four additions only: .github/workflows/opencode-memory-v2.yml and .github/tests/opencode-memory-v2/{runtime.py,test_runtime.py,README.md}. Default host plugin loading, one actual local embedding write, exact vector recall, graceful replacement with retained HOME and fresh configuration, and offline recall are separate assertions. No dependency injection, alternate runtime, compatibility shim, remote embedding fallback, or production capture.

Type of change

  • Documentation
  • CI / reusable workflow

Validation

  • Required pull-request checks pass
  • Generated or centrally distributed files were regenerated by their owning automation, not hand-edited — not applicable; no generated files changed

CI has not run at submission. No local test execution is claimed. New opencode-memory-v2 / fixture runs mocked unit tests before the exact-image runtime gate; existing hygiene/Helm checks remain unchanged. A passing startup/registration/health response alone is not acceptance. Gate requires successful local embedding write, exact memory ID/type/content and finite similarity ≥0.6, then the same recall on an offline replacement, plus cleanup. Compatibility is currently unknown.

Independent pre-PR reviews: adversarial review of all four files ADVANCE; scoped security review of workflow/runtime boundary ADVANCE; scoped DevOps review of complete new workflow ADVANCE; QA acceptance-coverage assessment COVERED. No unresolved Critical/High findings. Medium cleanup/mock/timeout findings corrected: seed removal failure prevents PASS, scripted mocks reject extra calls, global deadline reduced to 22 minutes with separate five-minute diagnostics/cleanup budgets inside a 30-minute job. Full published file blob hashes match reviewed local artifacts.

Verified CI result — 2026-10-05

Tested head 80ec41b8996b3f89c40197cc6989c0b9ad949216. Runtime run 37255749345 passed 64 unit tests, then failed real host registration: plugin 'opencode-mem@2.28.3' failed: Plugin failed to load. Image/platform, scoped volume preparation, non-root/container-security assertions and server-version readiness preceded this failure. The host reported a failed package state; the fixture now preserves that failure even when import failure leaves the plugin ID unavailable. Cleanup succeeded. No embedding write, vector recall or offline replacement was reached.

The underlying import/setup/native cause is unknown from the captured diagnostic; historical libc failures are not evidence of this release's specific cause. This combination has not passed stock-image acceptance; no shim/runtime/backend remedy is selected. Earlier cold-network assertion and timeout-diagnostic failures were fixture issues, not native compatibility proof.

Static run 37255749359 passed repository hygiene/Helm checks and detection. Packaging and GitOps updater were skipped. This draft remains unmerged with the runtime gate failed; no publication, GitOps change or live mutation occurred.

Precise cause from vendor diagnostics — 2026-10-05

Diagnostic run 37259957013, tested head 06bab9520689600c71259113cf0149e4a911a3e7, passed all 64 unit tests and failed the same package-load gate. The vendor-supported OPENCODE_PRINT_LOGS=1 with WARN level exposed the real cause through the existing bounded/sanitized failure capture:

  • @tursodatabase/database cannot resolve ./turso.linux-x64-musl.node.
  • Its fallback @tursodatabase/database-linux-x64-musl package is also missing.

This is a Turso native module-resolution failure during plugin loading on Linux x64 musl, before ONNX inference or memory write/recall/replacement. Current public npm metadata for database 0.8.1 lists Linux GNU optional bindings but no musl binding; the requested musl-package metadata returns Not found. The generic loader text blaming an npm optional-dependency bug is not evidence of that bug in this test. No native-library workaround has been implemented.

The latest static run passed hygiene/Helm validation and detection; package/updater were skipped. Cleanup succeeded. No production logging/configuration, credentials, image, GitOps or live-system change. This draft remains unmerged with failed runtime acceptance.

Impact and rollout

Producer/maintainer: makeitworkcloud charts/xnoto. Sole consumer: this new path-scoped, PR-only hosted Ubuntu workflow; its output is a CI result, not an artifact. Existing owned harness is adapted because upstream Ubuntu/Windows/macOS package smoke and chart static checks do not cover this exact Alpine embedded-host lifecycle.

Authored and submitted: test-only branch. Validation: automatic PR checks completed; static checks passed, runtime gate failed. Chart/image publication: unchanged/not selected; .github-only diff yields no changed chart, so packaging and postpublication GitOps updater are skipped. Chart version/configuration, images, GitOps consumer pins, reconciliation, production health and functional behavior: unchanged by this PR. Merge/publication/deployment/manual dispatch remain confirmation-gated and are not requested. Rollback: close this experimental PR; nothing is deployed.

Residual limitations: cold public npm/model downloads and transitive dependencies are nonhermetic. The PR-controlled test runs with hosted-runner Docker access; container hardening does not constrain arbitrary changes to the Python harness itself. No production credentials are available to it. Even a passing probe does not validate OpenCode tool dispatch/permissions, extraction/capture/privacy, multi-agent scoping, Kubernetes, ARM, disaster recovery, or production rollout.

Safety and secrets

  • Contains no plaintext secrets, decrypted SOPS values, state files, kubeconfigs, tokens, or private endpoints — password/token literals are explicitly public synthetic fixture values, not authentication material from any real account
  • No local OpenTofu init/plan/apply/destroy/import/state operations were run or claimed — plans come from pull-request checks
  • Breaking or irreversible effects are described above with rollback notes — no deployed changes

UUID-scoped disposable HOME/config volumes only; no production storage, auth, agents, providers, or MCP configuration. Apps run non-root/read-only with dropped capabilities, no-new-privileges, loopback listeners and no published ports. Scoped same-image preparation is offline and CHOWN-only. Warm replacement is network-none. No uploads/cache/artifacts; diagnostics are bounded and sanitized; cleanup failure fails the gate.

AI-assisted implementation and independent review; primary retained authorization, source verification, safety and delivery decisions.

@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown

Chart CI passed

Repository hygiene and Helm validation passed. View the workflow run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant