I decided to treat opencode as the operational control plane for how I work: one repo that holds global policy, agent behavior, and repeatable automation, with fast local execution over heavyweight services.

What We Built

• A Node.js-based configuration and policy repo focused on OpenCode agent behavior and guardrails.
• A policy-learning pipeline with both one-shot and daemon modes (npm run policy:learn, npm run policy:learn:daemon), plus install/start/stop/status lifecycle scripts for a local service wrapper.
• Git hook enforcement via simple-git-hooks, with tracked pre-commit logic that validates staged *.json and *.jsonc files.
• Documentation that anchors intent and operations (README.md plus policy-learning design and operations docs), so behavior is explicit rather than tribal.

Why We Built It

• I needed a single source of truth for agent execution policy that is easy to iterate locally and hard to drift from.
• Recent work shows a clear direction: tighten guardrails while expanding capability. The latest commit theme is explicit (a722c57 “tighten global home-directory permission policy”), while nearby commits add skills and remove outdated memory assumptions (ba6e78f, 3ec8193).
• Session history reinforces the same pressure: repeated checks on “what does my config look like” and “does it work” indicate reliability and inspectability were the immediate needs, not new platform layers.
• The most recently changed file being AGENTS.md is consistent with this: behavior policy is actively maintained as code, not treated as static prose.

How It Works

• Day-to-day control flows through npm scripts in package.json: learning runs directly, daemon mode supports continuous operation, and service scripts handle local install/start/stop/status/uninstall.
• Hook setup happens automatically through the prepare script, so repository safety checks are applied after install without manual steps.
• The repo structure keeps responsibilities separated: bin for operational commands, policy-learning for pipeline logic, skills for reusable capability definitions, and docs for design/operations references.
• The operating model is intentionally simple: local-first execution, policy encoded in repo files, and incremental hardening through small commits and session-driven adjustments.