Software Factory¶

SuperQode's Software Factory is the session graph plus model, runtime, harness, and policy lineage. It keeps the work order portable while workers change.

The principle is:

Do not lock work to one model, one provider, one harness, one runtime, one UI, or one subscription.

Factory-style systems often focus on model independence. SuperQode extends that idea to harness independence and local-first ownership:

• Any model: local OSS, BYOK cloud, ACP agents, runtime SDKs, and future routers.
• Any harness: coding, review, test, local-private, recursive, Omnigent-imported, or project-owned.
• Any operating mode: private, cheap, best, review, long-context, or no-subscription.
• Same graph: switches, forks, handoffs, approvals, and share artifacts stay tied to the work.

Core Model¶

A factory has a root session and many worker sessions.

root-session  auth-refactor
  +- coder-local-qwen        model=ollama/qwen3-coder     harness=coding
  +- reviewer-gpt5           model=byok/openai/gpt-5      harness=review
  +- tester-local-deepseek   model=local/deepseek-coder   harness=test

The graph records:

• provider/model/runtime
• harness id
• factory route or mode
• agent role
• model and harness lineage events
• handoff packet ids
• approvals and status

Routes¶

Routes describe intent instead of vendor names.

Factory Policy¶

Create a project-owned policy file:

:factory init-policy

or:

superqode factory init-policy

This writes .superqode/factory.yaml:

default_route: no-subscription
routes:
  no-subscription:
    allow_cloud: false
    allow_subscription_runtimes: false
    prefer:
      - ollama/qwen3-coder
      - local/deepseek-coder
  review:
    allow_cloud: true
    prefer:
      - byok/openai/gpt-5
      - ollama/qwen3-coder
    harness: review

The factory merges this file with built-in routes. The file belongs to the project and can be committed, reviewed, or generated by local setup flows.

Current Behavior¶

Factory switches are durable coordination events:

• switch-model records provider/model/runtime lineage and writes a next_turn intent.
• switch-harness records harness lineage and writes a next_turn intent.
• TUI and CLI show the current intent and privacy warnings.
• The local API exposes the same metadata for browser/mobile companions.

The active runtime continues safely until the next turn. Future runtime and picker integrations can consume the recorded intent without changing the session history format.

TUI Commands¶

Open the cockpit:

:factory
:switchboard

Create or inspect policy:

:factory init-policy
:factory policy

Set a route:

:factory mode no-subscription
:factory mode private
:factory mode best

Record a model switch on the active session:

:factory switch-model ollama/qwen3-coder
:factory switch-model byok/openai/gpt-5

Record a harness switch on the active session:

:factory switch-harness coding
:factory switch-harness review

Fork work to another model worker:

:factory fork-model --model local/deepseek-coder --role coder --goal "try a local implementation"

Fork work to another harness worker:

:factory fork-harness --harness review --role reviewer --goal "review the current patch"

Show lineage:

:factory lineage

CLI Commands¶

superqode factory status
superqode factory init-policy
superqode factory policy
superqode factory routes
superqode factory mode no-subscription
superqode factory switch-model ollama/qwen3-coder
superqode factory switch-harness review
superqode factory fork-model --model local/deepseek-coder --role coder
superqode factory fork-harness --harness review --role reviewer
superqode factory lineage

No-Subscription Mode¶

no-subscription is a first-class route for teams that want ownership and portability. It is designed for:

• local OSS models
• BYOK providers
• project-owned harnesses
• local session graphs
• portable share trees

Router integrations can use this route to block subscription-only runtimes and warn before moving local or private work to cloud providers.

Relationship To The Switchboard¶

The switchboard is the operational graph: sessions, child sessions, approvals, handoffs, and share trees.

The factory is the policy and lineage layer on top: model choice, harness choice, and route intent.

Use:

:switchboard

when you want to see or move between sessions.

Use:

:factory

when you want to change which kind of worker should handle the next part of the job.