Notion authoring edition · 0.1.31. Reviewed portable distribution: v0.1.31. Native adoption is checked separately.
Supporting files are in Files → references above.
Use for requested setup, adoption, migration or readiness assessment. Assessment is read-only. Preserve the project's purpose, existing tools, instructions, artifacts and useful work. Setup does not admit new product work.
Identify the owner, intended outcome, project records, execution environment, operator entry and delivery destination. Recover facts from the actual sources before asking the owner to repeat them. Use the existing project/adoption record; do not create a second tracker. Resolve the assigned Factory declaration from its owning context source. In our Notion recipe, the YAML code block is the original; a selected factory.yaml export records a particular version. Read its declared composition and source routes. It records intended choices; verify applied native configuration separately and preserve existing authority and holds.
Agent environment: selected client/host, native agent tools and models, assigned skills, identities/connections, effective permissions, native history, startup and recovery. T3 Code is a reference workspace, not a required Factory server. Another native tool is suitable only after its needed loading, execution and access behavior is checked.
Project foundation: authoritative context, goal and mandate, selected domain methods, native artifacts, meaningful acceptance checks and applicable standards. Software may use a repository; BI may use models and workspaces; research may use documents and datasets. Keep their native sources.
Operations & maintenance: the work/test/delivery/operating environments the task needs, observable failures, updater ownership, maintenance windows, recovery and relevant ongoing care. The agent host and the delivered product may run on different systems. A prototype does not require every production control.
These areas are preparation scopes, not three compulsory machines or access levels. Prepare only the capabilities the intended work requires. Reuse unchanged proof; recheck the affected capability after a relevant version, account, permission, configuration or dependency change.
Use the adoption guidance (references/adoption.md#update-an-existing-project) when an existing project should align with a selected reviewed Factory revision. Compare installed methods and local adaptations before changing files; preserve product work, context and current authority. A project visible in a workspace is not necessarily an adopted installation.
Resolve each artifact's original source. In the selected Notion recipe, shared method, policies and authored skills can live in Notion; project-native artifacts and technical work records remain in their native systems. Notion is replaceable. Until an explicit cutover, an existing source retains its authority for its version.
Before a project has its own Factory, the owner's Planning Agent can ask Foundation to prepare it. Select or create that project's context home, reuse its existing sources, and prepare only the declaration, skills and access the intended work needs. Its product goals, architecture and delivery belong there; the public Factory guide supplies reusable methods to select or link, not a document tree to clone. Hand the verified setup and remaining gaps to the project's AgentOps.
Keep project bootstrap instructions thin: common constraints, source routes and checks. Assign the role and selected skill explicitly; a role title or AGENTS.md does not load every skill or grant access. Preserve required references in the selected skill bundle. Identify source/version when materializing a worker's files or adopting a reviewed distribution. Do not invent a sync service or silently refresh installed skills.
references/github.md; a personal login or role name is not proof of the agreed boundary.