Decision requested: approve implementation of a lightweight, sovereign workflow layer built on assets already owned by João: Forgejo, markdown knowledge, LiteLLM, MCP, VSCodium/Cline, and the existing rabbithall admin cockpit.
1. Executive Summary¶
João's core requirement is not only data ownership, but workflow sovereignty: the ability to continue operating, developing, and making decisions even if a vendor, API, model provider, or regulatory environment changes unexpectedly.
The analysis shows that approximately 80% of the required sovereign layer already exists. Forgejo provides the git source of truth, LiteLLM already routes across 52 models and 6 providers, markdown memory contains the durable knowledge base, and MCP provides the bridge between tools and infrastructure.
The recommendation is therefore not to build a new framework. The board should approve a focused implementation that formalizes the existing assets into a sovereign workspace repository, exposes them through a clean developer cockpit, and keeps coding tools interchangeable.
Recommended decision: implement the sovereign workflow architecture now, using a phased approach that minimizes risk, avoids new platform dependency, and delivers immediate operational visibility.
2. Strategic Rationale¶
The current risk is workflow concentration: too much operational leverage sits in proprietary command syntax, IDE-specific conventions, and tool-specific habits. The business objective is to move the durable parts of the workflow into neutral, portable, version-controlled assets.
The proposed architecture separates the sovereign foundation from the replaceable interface layer. The foundation remains stable: git, markdown, model routing, memory, prompts, principles, and operating rules. The IDE becomes a replaceable skin.
This creates resilience against vendor lock-in, API restrictions, model availability changes, and future tool churn while preserving the daily convenience of modern AI-assisted development.
3. Recommendation¶
Decision Approve implementation of the Workflow Sovereignty architecture.
Scope Create jb-workspace, redesign the rabbithall control center into a cockpit, and adopt VSCodium/Cline through LiteLLM.
Principle Do not build a new orchestration framework; formalize and connect what already exists.
Outcome A portable, provider-independent developer operating layer with a single daily front door.
4. Target Architecture¶
The architecture has three layers: a sovereign foundation, a cockpit front door, and an interchangeable coding bubble.
Layer Purpose Decision
Foundation Durable knowledge, principles, Forgejo + markdown + prompts, memory, model routing, LiteLLM + MCP source control
Cockpit Single daily entry point for Build inside rabbithall
status, priorities, launch links,
and recent activity
Coding IDE and agent interface used day to VSCodium + Cline or Bubble day Continue.dev via LiteLLM
5. Implementation Scope¶
5.1 Sovereign Workspace Repository¶
Create a new Forgejo repository named jb-workspace. This becomes the canonical, version-controlled home for operating principles, persona, agent instructions, reusable prompts, stack inventory, and markdown memory.
The repository should be born empty and populated only with João's own content. It must not clone an external framework or import an external operating model.
5.2 Developer Cockpit¶
Redesign the existing rabbithall control center into a modern cockpit. The cockpit should show critical items, pending work, recent completions, service status, launch links, and drill-down views for infrastructure, applications, and curation.
5.3 Open Coding Interface¶
Adopt VSCodium with Cline or Continue.dev routed through LiteLLM. This preserves a modern developer experience while keeping model choice and provider access independent from the IDE.
6. Why This Should Be Approved¶
Board Concern Response
Cost Low incremental cost because most components already exist.
Risk Reduced by using existing infrastructure and avoiding a new custom framework.
Lock-in Materially reduced through markdown, git, LiteLLM routing, and open-source tooling.
Speed Fast first release: repository plus cockpit redesign can be implemented in phases.
Maintainability Improved by centralizing durable knowledge and keeping interfaces replaceable.
7. Implementation Roadmap¶
Phase Action Outcome
1 Create jb-workspace and populate Single source of truth core markdown assets. established.
2 Back up and symlink current Claude Existing workflow preserved persona into the repository. while governance improves.
3 Build cockpit page inside Daily operational visibility rabbithall with priorities, counts, delivered. and launch links.
4 Adopt VSCodium/Cline or Open-source coding interface Continue.dev through LiteLLM. with provider independence.
5 Later: expose skills-gateway as MCP Broader portability without and generate adapters for other premature complexity. tools.
8. Scope Control¶
The implementation should explicitly avoid three traps: building a custom orchestration framework, turning Hermes into the coding sovereignty layer, or designing tool-switching machinery before it is needed.
Hermes should remain focused on business automation. The sovereign developer layer should be lightweight, file-based, model-router aware, and tool-neutral.
9. Success Criteria¶
-
jb-workspace exists in Forgejo and contains the canonical operating materials.
-
Claude Code continues working unchanged through the symlinked persona file.
-
The cockpit loads inside rabbithall and shows critical, pending, recent, and service status information.
-
LiteLLM remains the model-routing layer for Claude, Grok, DeepSeek, local models, and future providers.
-
At least one open-source IDE workflow reads the same operating materials without rewriting them.
10. Decision Statement¶
The board should approve implementation. The proposal is strategically sound because it converts existing assets into a durable sovereign workflow layer, reduces lock-in, improves operational visibility, and avoids the cost and risk of building a new platform.