Glossary

Every term, defined.

27 terms from across the OOretz Factory product surface. Built for first-time readers and AI agents that need precise definitions.

A

AppManifest(a.k.a. manifest, app spec)

The structured JSON document the factory produces from your natural-language prompt. Lists entities, workflows, surfaces, and capabilities. Every build is driven by a manifest, and you can review/edit it before generation starts.

Appears in: Operator plan-review phase, /admin/factory/manifest-validator

Artifact

The downloadable output of a successful build: today a `.tar.gz` of the Next.js + libSQL workspace. Each artifact has a SHA-256 hash and a signed URL with a per-tier retention window (Hobby = 30 days today; Pro / Team / Enterprise retention values are planned). Desktop installers and mobile APKs are roadmap formats per ADR 0008.

Appears in: /admin/factory/artifacts, delivery phase of operator

B

Bridge node(a.k.a. bridge, build node, runner)

A real Linux or Windows machine the factory uses to execute builds. Not a sandbox, not a WebContainer. Linux bridge is "Runner-1" (already shipped). Windows bridge is an EC2 instance (in progress). Macs and mobile bridges are roadmap items.

Appears in: /factory/status, /admin/factory/fleet, /admin/factory/bridge-test

Build attempt

One pass through the compiler. A build can have multiple attempts because the repair agent edits files and retries — 6 build attempts per file with a 15-cycle total cap across the job. Most successful builds converge in 1-2 attempts.

Appears in: Trace tab on /admin/factory/job/[id]

Builder job

One end-to-end run: prompt → manifest → code generation → build → verify → artifact. When paid tiers ship, this is the unit that counts against a tenant's monthly quota. Cancelled jobs will not count. Today there is no quota system — Hobby tier is free with no counter.

Appears in: /factory/pricing per-tier quotas

C

Capability

A specific requirement extracted from your prompt — "needs Windows bridge", "needs print driver", "needs HIPAA-compliant storage". The capability resolver picks the bridge nodes and configuration needed.

Appears in: Operator plan-review, AppManifest.capabilities[]

Capability resolver

The component that translates your manifest into a set of bridge requirements + provider keys + storage configuration. Runs before generation. If a required capability is unavailable (e.g. Windows bridge is offline), the resolver queues the job.

Appears in: lib/factory/capability-resolver.ts

Capacitor

The cross-platform framework we use to compile web apps into native mobile shells (Android APK today; iOS planned). It wraps a webview inside a native app and provides bridges for camera, filesystem, etc.

Appears in: Mobile surface in capability resolver

Cmd-K

Keyboard shortcut to open the command palette in the operator. Type-to-search every navigation target, recent job, and starter prompt. Cmd-K on Mac, Ctrl-K on Windows.

Appears in: /admin/factory header chip

Compile-fix loop(a.k.a. repair loop, auto-repair)

The autonomous cycle that catches compile errors and asks the AI to fix them. Up to 5 retries per file. After 5, the loop gives up and reports the error in the proof pack.

Appears in: lib/factory/verification/repair-agent.ts

D

Design partner

A customer who works closely with us on a production app in exchange for 50% off Pro for life, industry exclusivity, direct line to engineering, and a real case study after v1.

Appears in: /factory/customers

E

Entity

A domain object the generated app manipulates — "Customer", "Invoice", "Vendor". Manifests list entities with fields and relationships. Per-entity generation produces cleaner code than whole-app generation.

Appears in: AppManifest.entities[], operator plan-review

H

Hardening

Continuous regression-testing the factory against a fixed set of 12 prompts. Tracks build / launch / screenshot pass rates over time. Goal is to know when we're ahead or behind on quality.

Appears in: /admin/factory/proof

I

Idempotency key

A hash of the prompt + tenant + day. If the same key arrives within 24h, the second submission returns the first job's ID instead of building again. Prevents accidental duplicate spend.

Appears in: lib/factory/orchestrator-helpers.ts

L

Launch verifier

The component that boots the built app on a bridge node, waits for it to be alive, captures a screenshot, and writes the result to the proof pack. Without launch verification, the system only knows the code compiled — not that it runs.

Appears in: lib/factory/verification/launch-verifier.ts

Launchpad

The public page at /factory/launchpad with 25 hand-curated starter prompts. Click any to deep-link into the operator with the prompt pre-filled.

M

Manifest

See AppManifest.

Multi-model gateway

The router that lets you hot-swap between Claude, GPT-5, Gemini, and Mistral per request. Twelve models, four providers. Cost-sensitive runs go to Mistral; high-accuracy runs go to Claude Opus.

Appears in: Operator model picker

O

Operator

The browser UI at /admin/factory where humans interact with the factory. Hosts the interview chat, plan review, build progress stream, and delivery panel. Distinct from the orchestrator (which runs server-side).

Appears in: /admin/factory

Orchestrator

The server-side function that drives a job through its full lifecycle: parse intent → resolve capabilities → scaffold → generate → verify/repair → package → return artifact. Streamed via SSE.

Appears in: lib/factory/orchestrator.ts

P

Proof pack

The structured evidence package generated for every build: prompt, manifest, generation trace, build attempts, repair cycles, launch result, screenshot, artifact hash. Saved to sf_factory_proofs.

Appears in: Proof tab on /admin/factory/job/[id], /admin/factory/proof matrix

R

Repair agent

The AI-driven component that reads compile errors + the broken file and writes a corrected file. Powers the compile-fix loop. Runs as a separate AI call per file.

Appears in: lib/factory/verification/repair-agent.ts

Repair cycle

One iteration of compile → fail → ask repair agent → rebuild. Capped at 5 cycles per file. In practice, most successful builds need 0-2 cycles.

Appears in: Trace tab, case study build reports

S

Surface

The output target of a build: desktop, web, mobile, or hybrid. Manifests can request multiple surfaces; the orchestrator dispatches each to the appropriate bridge.

Appears in: Manifest, operator filters, capability resolver

T

Template

A reusable starting-point project structure that the materializer copies before generation begins. Saves the AI from generating boilerplate it gets wrong (csproj files, App.xaml.cs wiring, etc.).

Appears in: /admin/factory/templates, /factory/gallery

Trace

The per-job timeline of AI calls, bridge minutes, tokens, latency. Shown as a tab on /admin/factory/job/[id]. Tells you exactly what your job cost and where the time went.

Appears in: Trace tab on job detail

W

Workspace

A throwaway directory on a bridge node where one job's files live during generation + build. Workspaces are isolated per job and destroyed after the artifact is shipped (snapshot kept for proof).

Appears in: lib/factory/bridge/* commands
© 2026 OOretz Factory · Precise language matters