Actionist vertical-app factory — first-principles program reset

Date: 2026-08-28 Status: research_only_reset_with_holds Owner: Actionist Program Driver Scope: strategy, contracts, evidence and dependency ordering; no client-app edits, deployment, admission or production mutation

North star

Actionist wins against Lovable by making a different promise: turn a known B2B outcome into a coherent, maintainable vertical product by selecting and binding the best proven capabilities from a very large heterogeneous corpus, then generating only the missing client-specific delta.

Lovable-style prompt-to-app generation is a benchmark and a reference point, not the architecture. The product is the factory: demand understanding, capability discovery, reuse-shape selection, host binding, deterministic composition, verification, release and learning. AFFiNE, Teable and Chatwoot are calibration donors and evidence of seams; they are not the product strategy.

The economic unit is a successful client workflow and then a maintained vertical product, not a generated screen, repository, component count or model token total. The factory is winning only when it repeatedly improves time to a verified workflow, quality, repair burden, runtime burden and cost per successful outcome against a focused custom-build baseline.

The three-block composition remains a calibration fixture. It can test contract shape, refusal, authority ceilings and measurement instrumentation. It cannot establish a vertical, a reusable block, product-market fit, qualification, admission or the factory moat.

First principles

1. Start with the outcome. A ProductSpec and DomainPack precede repository or

UI selection. Requirements must not inherit the shape of available code.

1. The atomic business unit is a solution atom. It names actor, trigger,

source state, decision, side effect, authority/approval, post-condition, recovery and audit evidence.

1. The reusable code unit is a capability in a declared reuse shape. A

repository is a source container that may yield several capabilities, one capability, a reference pattern or nothing reusable.

1. Standardize seams, not internals. Host identity, tenancy, data ownership,

UI/token context, settings/navigation, connector authority, runtime and evidence are the interoperability boundary. Donor internals remain intact when that is the cheaper and safer shape.

1. Evidence is part of the product. A build, a screenshot, a schema-valid

record or a source URL cannot substitute for tenancy, authority, visual, runtime, rollback or whole-workflow evidence.

1. Deterministic systems own safety. Identity, dependency closure, port

compatibility, route/table/migration conflicts, authority ceilings, evidence minima and release manifests are machine-checked. Models may interpret, propose and write bounded transforms; they cannot grant authority or invent a missing contract.

1. Unknown is a result. UNDERDETERMINED, not_run and NOT_ADMITTED are

useful outputs. Candidate evaluation has its own scope; production admission keeps strict R-SCOPE and never treats a research result as permission.

1. Learning is attributed. Promote or demote a capability from repeatable

outcome, quality, adaptation, operational and maintenance evidence—not from corpus size, stars or repeated prose.

The reusable-unit stack

Supported reuse shapes are independent of capability kind:

• intact_service — retain the upstream runtime and data ownership behind a

protocol;

• intact_fork or embedded_module — retain a donor application/surface where

its UI, state and navigation are the value;

• transplanted_subsystem — own a product-defining slice deliberately;
• extracted_package — isolate a narrow feature with a small dependency

closure;

• adapter — retain an external system and expose a typed host interface;
• generated_pattern — reproduce a proven architecture without copying the

source;

• template_or_archetype — reuse a tested application skeleton and variation

points;

• custom_delta — write only what is genuinely client- or niche-specific;
• reference_only — retain design/architecture learning without reproducing

code.

The seven linked records from Sprint 2 remain the minimum governance split: CapabilityContract, PackagingProfile, HostContract, BindingPlan, QualificationDossier, RegistryRecord and ReleaseManifest. They are linked, not fused into a universal object.

The complete repo-to-module factory

OutcomeSpec + DomainPack + ProductSpec
  → demand/atom query
  → local-first source graph and candidate funnel
  → source identity, rights and architecture map
  → capability boundary + reuse-shape decision
  → dependency/SBOM/upgrade closure
  → seven linked module records
  → deterministic surgery plan and bounded adaptation
  → host/data/identity/UI/connector/runtime binding
  → candidate-evaluation solver
  → staged isolated build and whole-workflow verification
  → qualification dossier
  → scoped human admission
  → release, rollback and attributed learning

The stages have different stop conditions:

Client demand to product runtime

Client context and discovery
  → OutcomeSpec (buyer, painful job, value measure)
  → DomainPack (entities, roles, events, vocabulary, invariants)
  → ProductSpec (workflows, screens, actions, failures, acceptance, non-goals)
  → capability query (atoms, ports, host/data/action constraints)
  → typed candidate graph (local first, reference-only separated)
  → deterministic elimination + bounded planner choice
  → AssemblyPlan and surgery budgets
  → staged host binding
  → read-only/approval-gated preview and complete-workflow proof
  → qualification dossier and client Accept/Revise gate
  → human admission for the exact host scope
  → ReleaseManifest, deployment and rollback
  → operation traces, economics and learning feedback

Agent roles are deliberately narrow: interpreter, retriever, deterministic solver, planner, binder and verifier. The solver cannot choose an infeasible candidate; the binder cannot write outside its allowlist; the operator owns business equivalence, destructive authority and release.

Shared boundaries

What survives, what is contained, what is rejected

Smallest dependency-ordered build sequence

This is the smallest sequence that can test the factory thesis without pretending that a donor demo is a product. It is a future build plan, not an authorization to modify client applications.

The first meaningful competitive test is R10. If the assembly path does not improve a complete workflow against a focused custom baseline without weakening security, UX or maintainability, increasing corpus size will not fix the strategy.

Explicit falsifiers

These are pre-registered reasons to stop, narrow or redesign. They are not predictions of failure.

Current evidence position

Solved at research or local-precedent level

• The demand → supply → composition → runtime → learning decomposition exists in

the 18-domain/15-part map.

• The Block Hub distinguishes components, surfaces, capabilities, product modules,

engines and composition recipes.

• The seven linked records, reuse-shape taxonomy, normalization surgery classes,

runtime profiles, evidence ladder, rollback vocabulary and learning signals are specified in Sprint 2.

• The Framework Registry research packet is verified at 24 frameworks, 62 edges

and 10 gaps, with maturity 0/9/14/1/0/0; measured and operational remain zero.

• SISOCRM and the BYK/Fahmy estate demonstrate real seams worth mining: host

routes, intact donor origins, host-session code, native/iframe alternatives, donor-owned data and local receipts. They do not prove a general factory.

• The corrected three-candidate solver demonstrates a structurally feasible

candidate-evaluation projection with strict production R-SCOPE refusal. The three-block host result is a synthetic calibration fixture only.

Unsolved at product-factory level

• A reachable client outcome, ProductSpec and client acceptance record.
• A repeatable repo-to-module golden path whose cost is measured on real source.
• General host identity, tenant, settings/navigation, data, token, connector and

runtime contracts that pass negative tests across reuse shapes.

• The actual distribution of cosmetic, boundary and architectural adaptation

cost, upgrade/recovery burden and glue budgets.

• A complete workflow that beats a focused custom baseline on quality and cost.
• A qualification dossier, human admission, release, rollback rehearsal and

production learning signal.

• The authoritative large local corpus path/query interface and a production

learning loop that can safely rerank it.

The current machine observation found no donor listeners on the AFFiNE, Teable, Chatwoot or assembled-portal ports and no Docker executable; historical service receipts are retained as historical. No donor RAM or process burden may be inferred from the synthetic host's one-process measurement.

Evidence anchors

• knowledge/00-MASTER-SYNTHESIS.md — strategic thesis, five planes, reuse

shapes and known unknowns.

• knowledge/01-DOMAIN-MAP.md and site/system-map/data/parts.json — 18

domains and 15 moving-part ownership map.

• knowledge/block-hub/README.md — six-level hub and business lifecycle.
• research/workstreams/2026-08-27-sprint-2/convergence/S2-CONVERGENCE.md —

seven-record family, solver, host and runtime decisions.

• research/actionmodel-builder-research-2026-08-26/outputs/first-principles-framework.md —

solution atoms, evidence boundary and authority model.

• ../../apps/AutoSaaS/framework/autosaas-method.md and

../../apps/AutoSaaS/framework/code-harvest-protocol.md — existing outer factory loop and local-first harvest protocol.

• ../../apps/SISOCRM/ — actual host, manifest, native/iframe and session seams;

inspect without modifying the client app.

• ../fahmy-2026-08/docs/client-platform/implementation-manager/evidence/affine-existing-final/receipt.json —

direct historical AFFiNE integration receipt.

• ../fahmy-2026-08/docs/client-platform/implementation-manager/evidence/teable-data-final/teable-data-final-receipt.json —

direct partial Teable receipt.

• ../fahmy-2026-08/integrations/chatwoot/CHATWOOT_INTEGRATION.json and

../../../bykonz-archive-2026-08-23/bykonz-local-operator-bundle/verification/chatwoot-w1-acceptance/AMENDED-RECEIPT.json — direct Chatwoot runtime/hold evidence.

• dependency-task-graph.json and solved-unsolved-evidence-ledger.json in

this directory — machine-readable dependency and evidence projections for this reset.

Boundary and operator gate

This reset does not modify SISOCRM, BYK/Fahmy, prior client projects, the canonical knowledge spine or the public site. It does not clone or execute candidate source, read client records, deploy, qualify or admit a module. A future R1/R11 decision needs an explicitly named operator/client authority; silence is not approval. The existing AFFiNE, Teable and Chatwoot statuses stay NOT_QUALIFIED / NOT_ADMITTED.