Add a portable owner-agent entry for Factory

README.md

@@ -2,7 +2,7 @@
 
 # Factory
 
-Revision: 0.1.18 · Updated: 2026-10-19
+Revision: 0.1.20 · Updated: 2026-10-22
 
 A practical method for building and improving applications with coding agents.
 
@@ -28,6 +28,23 @@ owns the application's setup and work. The AgentOps conversation in the Factory
 repository develops Factory itself; it is not a central queue for every project.
 Share a relevant finding between projects when useful, with an explicit handoff.
 
+## Use Factory from your own AI agent
+
+Give your everyday AI agent the [Factory entry skill](agent-ops/factory-entry/SKILL.md).
+It tells that agent where each request belongs:
+
+- Work on Factory's method goes to the Factory repository's AgentOps.
+- Work on an application goes to that application's own AgentOps.
+- A request spanning several applications becomes one bounded handoff per lead,
+  and your agent coordinates what they share.
+- "Help me make this machine a Factory host and explain its role" loads
+  Foundation and its existing host setup guide.
+
+Your agent carries the request, candidate, authority and holds between leads and
+follows up. It does not become a lead or gain approval rights. Install it with the
+[setup guide](foundation/factory-foundation/references/setup.md#the-owners-own-ai-agent);
+installed, discovered and actually used are separate checks.
+
 ## Why I built this
 
 I’m building Factory to give software work with agents a modular structure, from

VERSION

@@ -1 +1 @@
-0.1.19
+0.1.20

agent-ops/factory-entry/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: factory-entry
+description: Use when an owner's everyday AI agent is asked to use Factory, start or follow up work, route a request to the right project, or make a machine a Factory host and explain its role. Routes to the existing project lead; it is not any project's lead.
+license: MIT
+metadata:
+  version: "0.1.20"
+  updated: "2026-10-22"
+---
+
+# Factory Entry
+
+You are the owner's own AI agent. You coordinate the owner's goals across their
+projects. You do not become a project's lead, a host administrator or an approver.
+
+Factory's roles, each a separate canonical skill:
+
+- `factory-agent-ops`: the lead in one project's pinned AgentOps thread. It owns
+  that project's priorities, workers, review and acceptance within its mandate.
+- `factory-foundation`: prepares and repairs host and project conditions, and holds
+  the reusable setup method, including host continuity.
+- ADLC skills (`factory-triage`, `factory-spec`, `factory-implement`,
+  `factory-review`, `factory-security`, `factory-evaluate`): run the concrete task
+  under a lead.
+
+Load a peer skill only when the request needs it. Resolve it by name in your native
+skill catalogue, or at its actual installed path. If it is not installed, you may
+read it explicitly from a reviewed Factory checkout. That is explicit loading, not
+native discovery, and a path you cannot read grants nothing.
+
+## Route the request
+
+- **Factory method development** goes to the Factory repository's existing AgentOps.
+- **Work on an application** goes to that application's existing AgentOps.
+- **Several applications** need one bounded handoff per existing lead. You
+  coordinate any shared dependency and ordering between them.
+- **Missing or stale recipient:** reconcile the actual native project, workspace and
+  thread identity with the retained adoption record. A familiar thread title is not
+  authority. If no lead exists, ask the owner, or ask Foundation to establish one.
+  Never fall back to Factory's own lead, and never start a second lead.
+
+A lead that could do the work is not therefore the right entry. Within that lead,
+an idea or research request ends in a recommendation, not admitted work. An
+accepted task or backlog proceeds under existing authority. A setup or readiness
+gap goes to Foundation for the affected capability only, not a rerun of all
+setup. A follow-up returns to the same lead, and a candidate for human review goes
+to the owner.
+
+## Hand off and follow through
+
+Each handoff states the following separately:
+
+- the request and its intended outcome;
+- the current candidate and evidence;
+- admission authority and delivery authority, with any scoped delegation;
+- constraints and current holds;
+- the next action and who holds it.
+
+Keep these states apart: queued, consumed or acknowledged, actually started,
+blocked, and delivered. A sent message is not started work. Read the recipient's
+actual native state before any retry, correction or new assignment. Do not
+interrupt an active worker or add a competing writer.
+
+The owner's two decisions stay with the owner unless they delegated them for a
+defined scope: admitting work, and accepting delivery before merge or release.
+Green CI or a positive review is not merge permission, and silence is not
+approval. A changed candidate needs its decision checked again, and branch
+protections still apply. Bring a genuinely missing owner decision forward plainly,
+with the candidate and your recommendation, and keep following it up.
+
+After compaction, a restart or a new session, reread this skill, the owner's
+current request, the retained record, recorded decisions and holds, and each
+recipient's native state before taking any effect.
+
+## Make this machine a Factory host
+
+For "help me make this machine a Factory host and explain its role", load
+`factory-foundation` and follow its setup guide, including its section "Keep the
+host ready after restart". Recover the intended host, execution account, harness,
+role, clients, recovery holder and existing project leads from the adoption record
+before asking anything. Ask only for choices that are genuinely missing. Apply only
+setup that is already authorized and routine. Keep the owner's own account and
+personal connectors separate from the execution account.
+
+Explain to the owner who plans and coordinates, who owns each project, who
+executes, and who accepts delivery. Report configured, running, reachable,
+resumed and demonstrated useful work as separate results.
+
+Whether this skill was requested, installed, discovered in your session, and
+actually used are four separate claims.

docs/architecture.md

@@ -1,12 +1,13 @@
 # Responsibility and access
 
-Revision: 0.1.19 · Updated: 2026-10-21
+Revision: 0.1.20 · Updated: 2026-10-22
 
 Factory has three responsibilities around existing tools. It has no server,
 provider adapter, task database or application runtime of its own.
 
 | Responsibility | Owns | Does not establish |
 | --- | --- | --- |
+| Owner's own AI agent (`factory-entry`) | Routing each request to the right existing project lead, bounded handoffs across projects, and following them up | A project's priorities, workers or acceptance; approval, merge or administrator rights |
 | Foundation | Project context, native setup, access choices and readiness checks; repair when these change | Product scope, continuous execution or readiness merely because files were installed |
 | Host coordinator (optional) | Host continuity, maintenance shared by several projects, and repair requests to Foundation, within an explicit owner mandate | Product priorities, worker assignments or acceptance in a project; administrator rights or personal connectors |
 | AgentOps | Research, priorities, assignments, worker model choices, reviewed skill/context improvements and acceptance within delegated authority | Administrator access, permission to bypass review or self-installed skills |

docs/qualification.md

@@ -1,6 +1,6 @@
 # Qualification
 
-Revision: 0.1.19 · Updated: 2026-10-21
+Revision: 0.1.20 · Updated: 2026-10-22
 
 This record distinguishes source review, disposable exercises and observed native
 operation. A package release does not qualify another host, every future update
@@ -9,7 +9,8 @@ remain with the installation; public issues track the remaining acceptance work.
 
 | Boundary | Observed evidence | Limit / next check |
 | --- | --- | --- |
-| Package | Eight portable skills, metadata/link checks and staging tests | Mechanical checks do not establish agent decisions |
+| Package | Portable skills (nine from 0.1.20, with `factory-entry`; eight before), metadata/link checks and staging tests | Mechanical checks do not establish agent decisions |
+| Owner entry and all-skill staging (0.1.20 candidate) | 2026-10-22: [Factory #91](https://github.com/arcitai/factory/issues/91) source change, after an owner-side planning agent sent application work to the Factory repository's AgentOps as if it were Factory's general entry. That agent had no Factory skill enabled (owner report, not reproduced here). Adds the `factory-entry` skill, an `all` mode for the existing stage helper, and setup guidance for installing, discovering and using the entry. Portable skills and staging were chosen; plugin packaging stays optional. On the candidate, the package check passed with 9 skills and 0 errors, and 16 unit tests passed. All-set staging from the frozen source snapshot produced 9 skills and 28 manifest-bound files. Source candidate only; not delivered, released or installed | See the delivery PR for representative caller outcomes and independent review of the exact candidate. Installation, discovery and use in the owner's active caller have not been run; staging installed nothing |
 | Host continuity and maintenance (0.1.19 candidate) | 2026-10-21: [Factory #83](https://github.com/arcitai/factory/issues/83) source change, after an installation could look ready while operator apps did not start after login and no maintenance schedule was active (owner report, not reproduced here). Setup, adoption and architecture now describe the optional host coordinator, separate startup stages, one owned nightly maintenance opportunity, scoped holds and a same-host recovery copy. The existing owner coordinator reported one actual scheduled wake on 2026-10-21. On the frozen candidate: `scripts/check.py` passed with 8 skills and 0 errors, 11 unit tests passed, and staging Foundation produced its 9 portable files plus a manifest, which were not installed. In a fresh Sol 6.1 Max context, one application each of four synthetic cases matched the retained rubric (lead assessment, evidence kept privately): independent source work continued without a hold; a startup or wake was kept apart from recovery; unknown local account-tool exposure stayed unknown; and a real maintenance hold kept its timeouts and restored prior states. An earlier rehearsal was not run, because its brief prohibited the available reader; it is neither a pass nor a failure | These are bounded synthetic decisions, not live proof of boot, update, reconnect or isolation, and not a reliability result. That single wake is not proof of reboot, of operation with the Mac disconnected, or of full recovery. Controlled reboot, login and reconnect, safe update and continuation, and the host gates remain open live acceptance; this change marks none of them complete. Independent review of the exact final source is pending in the delivery PR |
 | Production artifact evidence (0.1.18 candidate) | Reconciled 17 October 2026 from product-lead handbacks ([Factory #76](https://github.com/arcitai/factory/issues/76); not reproduced here). OPD: the source expected eight embedded editor assets, but the installed executable held six and served editor-not-built. Its six tests substituted a `#[cfg(test)]` `tests::BUNDLE_FILES` list, while production uses `OUT_DIR/bundle.rs`, so those tests did not exercise production inclusion. The OPD lead's original handoff left a production smoke optional; the corrected R10 proof gate made it required. A same-source replacement was atomically adopted at 06:17:35Z (transferred receipt). AIOS: the contrast build installed at 06:18:55Z (298 files). Bridge: the owner passed queue history. The lead checked retained artifacts offline against the eight source-derived names: the old six-asset output was rejected for missing `editor.js` and `panel.js`, the fresh eight passed, and the R10 manifest and receipt agree. Six of the eight assets are runtime bytes; two are build provenance | Offline reuse of historical evidence; no binary was run, and this does not show that the method caused the recovery. Still open: the OPD native workflow and app-origin binding, and the AIOS native colours and opening. The missing Bridge toast is not a proven defect; no custom Undo is authorized. In one fresh-context rehearsal of five incident packets, every decision kept these limits: the incomplete package, the installed but unaccepted workflow and visual checks, the toast without an established contract, and the dropped accepted centre amendment. This tested decisions only, with no live product action and no claim of general reliability. Independent review of the exact candidate and its checks is recorded in the delivery PR |
 | Blocked-request follow-through (0.1.17 candidate) | 2026-10-15, after the held OPD request recorded below ([Factory #32](https://github.com/arcitai/factory/issues/32); coordinator native UI actions plus Factory native readback). Declining the held compound shell call failed it without running it, but the run stayed active and proposed a second shell change before the prepared text-only correction arrived. The coordinator then cancelled that held call: neither call ran, the run was interrupted and ended with nothing pending, and its pre-recovery checkpoint was kept. The OPD lead sent its accepted native-file-only instruction to the same worker at that checkpoint; the next run completed native file changes with no shell or approval items and nothing pending while still active | Operator-assisted progress after an interrupted blocked attempt, not an automatic wake, autonomous responder, uninterrupted run, completed diagnostic checks, review or product delivery, or OS isolation. The two settled requests are not to be re-disposed. The source guidance followed this event and did not cause it. Source checks and independent review are recorded in the delivery PR |

foundation/factory-foundation/SKILL.md

@@ -3,8 +3,8 @@ name: factory-foundation
 description: Prepare or assess a software project's engineering foundation and its execution host, including reproducible setup, real checks, documentation, CI/delivery, native harness access and GitHub work tracking.
 license: MIT
 metadata:
-  version: "0.1.19"
-  updated: "2026-10-21"
+  version: "0.1.20"
+  updated: "2026-10-22"
 ---
 
 # Factory Foundation
@@ -73,6 +73,8 @@ Prepare only the chosen capabilities:
 - Stage and review selected skills before native project/profile adoption.
   Keep one canonical copy, verify discovery in each chosen harness and preserve
   local adaptations on updates. Never install personal context as a dependency.
+  For the owner's own AI agent, adopt `factory-entry` as in
+  [the setup guide](references/setup.md#the-owners-own-ai-agent).
 - Prepare meaningful project checks, work tracking and delivery protections.
   Preserve existing field/label conventions and read settings back from GitHub.
   A local workflow file does not prove service-side protection is enabled.

foundation/factory-foundation/references/adoption.md

@@ -1,6 +1,6 @@
 # Adoption record
 
-Revision: 0.1.19 · Updated: 2026-10-21
+Revision: 0.1.20 · Updated: 2026-10-22
 
 Foundation identifies the appropriate existing project/adoption record and
 establishes the relevant choices. AgentOps maintains them and scoped exceptions
@@ -85,6 +85,10 @@ Reuse the following existing choice families only where they matter:
   prevail. Refresh it when models, requirements or retained outcomes change.
 - Selected skills, Factory tag/revision, stage hashes, installed paths, preserved
   local changes and observed native discovery.
+- The owner's own AI agent: which agent and harness hold `factory-entry`, and its
+  requested, installed, discovered and used states recorded separately. Also the
+  current lead for each project it routes to, so a resumed caller can find the
+  right recipient again.
 - Ops thread identity, project/workspace binding, role/source paths, pin and
   auto-settle choice; explicit source loading distinguished from native discovery.
 - Each client's saved service connection and Local environment choice; observed