Software decisions¶
Decisions for Conductor software packs. Updated 2026-07-22.
Org model: docs/org-map-model.md is canonical. This file locks Software line choices.
Conflict note: Archived Workspace AGENTS still describe older rules (Lab = showcase only; Portfolio = maintenance; deploy default = ai-sandbox). Conductor units prefer these decisions. Update Workspace AGENTS in a later pass.
Org-level locks (2026-07-22)¶
| ID | Choice |
|---|---|
| Lines | Product, Software, Editorial, Services, Operate + Portfolio Office |
| Roles | First-class hats for agents/Hector; no governance boards |
| Career | Out of Conductor until promoted |
| Product→Software gate | Hard for Portfolio/revenue; soft for Lab experiments |
| Project strip | GitHub work contract |
| Arch domains | arch-checklist under Software Design (fill cards as needed) |
Modular model (LOCKED intent)¶
Separate two layers:
1. Workflows (stable choreography)¶
Ordered stages of software work, e.g.:
Prototype → Design → Implement → Verify → Promote → Deploy → Document/catalog → Maintain
A workflow says what step happens when, not which vendor or template fills the step.
2. Inventories (pluggable options)¶
For some steps, Conductor holds an inventory of options. Choosing one option injects that option’s details (guardrails, templates, secrets, hostnames, patterns).
Example — Deploy inventory (non-exhaustive):
| Option ID | Meaning |
|---|---|
host.konstant |
Default self-host on konstant-server |
host.vercel |
Standalone on Vercel |
host.gcp |
Future / optional |
host.vps-legacy |
Decommissioning — inventory entry for history/migration only, not for new work |
Example — Deploy shape inventory (orthogonal to host when self-hosted):
| Option ID | Meaning |
|---|---|
shape.static |
Static files + nginx |
shape.dynamic-socket |
HTTP/MCP + socket activation |
shape.dynamic-always-on |
Warm process (documented why) |
Assembly: Workflow picks the Deploy step → agent/Hector selects inventory options → pack includes the matching detail units. Same idea can apply later to Design, Auth, Secrets store, etc.
This replaces “one giant pattern doc” with workflow + inventories.
D1 — Estates — LOCKED¶
| Decision | Choice |
|---|---|
| Start | Always Prototype |
| Default landing | Lab (tools, showcases, MCP, …) + role tag |
| Portfolio | Revenue / commercial |
| Skip Lab | Allowed when already commercial (Prototype → Portfolio) |
| Org (D1a) | 1 — Lab hector-sanchez-eu, Portfolio Konstant-Ventures |
| Lab catalog (D1b) | 1 — All Lab apps get /lab/<slug>/ after live URL |
| Graduation (D1c) | 1 — Explicit Lab → Portfolio when revenue appears |
| Client sites (D1d) | Still provisional 3 (Services owns engagement; Lab if craft showcase; Portfolio if productized) unless you change it |
Role tags (not estates): showcase | tool | platform | library | end-product | agent-runtime | other
D2 — Hosting inventory — LOCKED¶
| Option | Status |
|---|---|
host.konstant |
Default for new self-hosted work |
host.vercel |
Allowed alternate for suitable standalone apps |
host.vps-legacy (ai-sandbox) |
Inventory only / migration — do not choose for new work |
host.gcp (etc.) |
Placeholder until filled |
D2a DNS: 2 — long-term <slug>.hectorsanchez.eu terminates on konstant once VPS is gone. During cutover, record actual hostname on the issue; ask if ambiguous.
D3 — Deploy step: workflow vs inventory — LOCKED + one open¶
Locked¶
- One Deploy stage in the high-level workflow for all apps.
- Details come from inventory picks (host + shape), not from rewriting the workflow.
- Old hectorsanchez.eu monorepo
content/lab/docs are historical evidence, not live templates. - CI/CD after bootstrap remains the steady state for self-hosted options.
D3a — Where inventory implementation artifacts live — LOCKED¶
Choice: 1 — Conductor owns executable templates (nginx snippets, GitHub Actions workflows, bootstrap scripts, pattern trees), not only prose guardrails.
Why: A Conductor-side agent will analyze outcomes and improve options over time; templates must live in the same governed repo as inventories/workflows so proposals/PRs can update them together (issue → approval → PR already exists for corpus/docs).
Implications:
- Add a Conductor tree such as
templates/deploy/<host>/<shape>/(exact layout TBD) as source of truth. - Pipeline Management / konstant install scripts consume/copy from Conductor (or call into this repo), they do not fork divergent YAML long-term.
- Inventory option units (
sw.pattern.*, futurehost.*) carrytemplate_refinto that tree. - Improvements go through Conductor change control (proposal issue + approval), same as other governed knowledge.
Supersedes earlier recommendation of D3a:2.¶
D4 — Deferred — LOCKED¶
Design-record/ADR, test matrix, global code style, mobile — later.
Implied next inventories (not filled yet)¶
| Workflow step | Inventory examples to flesh out later |
|---|---|
| Design | (gap) ADR-lite vs none; API-first vs UI-first |
| Implement / stack | language/framework defaults per app-kind |
| Verify | smoke-only vs checks matrix (D4) |
| Secrets | Bitwarden+GitHub vs Vercel env (tied to host option) |
| Auth | MCP bearer, none, OAuth, … |
| Document | Lab catalog+release vs README-only |
Edge cases (short)¶
| Case | Handling |
|---|---|
| Hobby tool | Prototype → Lab + tool + catalog (D1b:1) + host.konstant |
| Public experiment | Lab + showcase |
| SaaS | Prototype → Portfolio or Lab then graduate (D1c) |
| Lab starts earning | Graduate to Portfolio |
| Vercel frontend | Lab/Portfolio + host.vercel |
| Old VPS app | Migrate via host.vps-legacy runbook → konstant/Vercel; no new apps there |
| Client billable site | Services engagement; Lab if showcasing craft; Portfolio if productized (D1d:3) |