Require evidenced Foundation readiness and maintainable handoff

VERSION

@@ -1 +1 @@
-0.1.11
+0.1.12

docs/qualification.md

@@ -1,6 +1,6 @@
 # Qualification
 
-Revision: 0.1.11 · Updated: 2026-10-11
+Revision: 0.1.12 · Updated: 2026-10-11
 
 This record distinguishes source review, disposable exercises and observed native
 operation. A package release does not qualify another host, every future update
@@ -10,6 +10,7 @@ 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 |
+| Foundation readiness handoff (0.1.12 candidate) | 2026-10-11: [Factory #27](https://github.com/arcitai/factory/issues/27) source change after an AIOS assessment accepted a stale mandatory authoring self-dependency, its disabled private reporting was found only by readback, its lead could not read its private record, and Project1's current README kept stale pre-delivery claims (coordinator observations, not reproduced here). Package, unit and staging checks only | Behavioral evidence and independent review are pending in the delivery PR. Native binding/authentication behavior stays with [Factory #3](https://github.com/arcitai/factory/issues/3); Markdown does not repair it |
 | Persistent choices (0.1.10 candidate) | 2026-10-10: a fresh native Astra xhigh context answered four textual cases against `7f846946`: hypothetical settings stayed unauthorized; external read access retained scope and removal; provider-wide controls did not become project isolation; uncertain application, upgrade drift and expired exceptions required reconciliation | Method rehearsal, not live grant/revocation or a reliability measurement. Independent review of the combined source/presentation is tracked in the delivery PR |
 | Engineering Foundation (0.1.9) | 2026-10-10: [PR #24](https://github.com/arcitai/factory/pull/24) and release passed checks and independent review. The selected native scopes matched all 48 staged files; AgentOps explicitly reread the five changed Foundation files. AIOS' own AgentOps assessed its repository against the adopted method and actual build/review/pilot evidence | Explicit source loading is distinct from automatic instruction discovery. The optional three-hour CI profile has not been deployed or observed as a schedule; it enables no schedule itself |
 | Writer workspace selection (Nightly 2873) | 2026-10-10: native worktree-bound launch started a Factory writer at the expected revision and workspace. An AIOS child created through ordinary delegation remained on main with no worktree; it was stopped before edits, its stale command approval declined, and a separate native-bound writer was verified before implementation | Assisted recovery exposed ambiguous launch guidance, now clarified. A prompt is not a native binding; this does not prove automated recovery for every failed launch or OS isolation between roles |

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.10"
-  updated: "2026-10-10"
+  version: "0.1.12"
+  updated: "2026-10-11"
 ---
 
 # Factory Foundation
@@ -85,17 +85,27 @@ Prepare only the chosen capabilities:
   and encrypted-disk unlock need an explicit recovery route. Preserve skill-local
   changes when adopting a new reviewed version.
 
+Before finishing, make one short consistency pass over the sources relevant to
+the intended work, as described in [project context](references/context.md#find-the-source-before-writing).
 Finish with one short readiness result in the existing project record, scoped
 to the intended task. For each relevant capability, identify its host/repo scope,
 owning source, **verified**, **required gap**, or **conditional/not needed**
 disposition, and dated proof or the next action and responsible role. Explain
 conditional choices; do not treat an unchecked requirement as not needed.
+Mark a capability verified only from an actual check, readback or retained dated
+proof; a document, configuration file or earlier claim alone is not that proof.
+An unchecked, inaccessible or contradictory prerequisite stays a required gap with
+its observed evidence, source and date, plus the next action and responsible owner.
 Include versions without secrets; keep identity details in the private installation
-record. Hand this result to AgentOps, which can start authorized, ready work and
-route setup repairs back to Foundation. ADLC keeps
+record. Hand this result to AgentOps, which maintains the project's mandate,
+readiness and agreed upkeep, starts authorized, ready work and routes setup
+repairs back to Foundation. ADLC proves the changed task and keeps
 affected application sources and checks current during delivery. A gap holds the
-dependent capability, not unrelated work. Preserve unchanged proof rather than
-rerunning the entire installation for every task.
+dependent capability, not unrelated work. A native binding, authentication or
+capability gap holds only the work depending on it; keep the current task and
+its responsible next action visible for AgentOps' operator path. Editing these
+sources does not repair a native failure or prove autonomous operation.
+Preserve unchanged proof rather than rerunning the entire installation for every task.
 Preserve native history and recovery material during migration. Retiring an old
 runtime is a separate deliberate step after its replacement is qualified.
 Foundation installs no Factory daemon and grants no authority beyond the request.

foundation/factory-foundation/references/adoption.md

@@ -1,6 +1,6 @@
 # Adoption record
 
-Revision: 0.1.10 · Updated: 2026-10-10
+Revision: 0.1.12 · Updated: 2026-10-11
 
 Foundation identifies the appropriate existing project/adoption record and
 establishes the relevant choices. AgentOps maintains them and scoped exceptions
@@ -9,6 +9,13 @@ do not create a separate register or require the whole inventory for every proje
 Record choices that need to survive the task, affect later work or need removal,
 not every transient task choice. Unknown is a visible gap, not a made-up default.
 
+Name the record's actual maintainer: a person/operator or concrete authorized role,
+the portion and location each may maintain, and the access limit. If the project's
+lead cannot read or update the private record through its effective boundary,
+record that limitation and the supported handoff, such as sanitized changes passed
+to the operator who holds access. Do not claim independent lead upkeep, copy private
+details into a second register or broaden access to close the gap.
+
 Version safe project-shared policy in the repository where useful. Keep host
 identities, private paths, account references and sensitive evidence in the existing
 private installation record; share only sanitized summaries. Credentials belong

foundation/factory-foundation/references/context.md

@@ -1,6 +1,6 @@
 # Establish useful project context
 
-Revision: 0.1.9 · Updated: 2026-10-10
+Revision: 0.1.12 · Updated: 2026-10-11
 
 Use during setup or a scoped readiness assessment. Start with the actual repo,
 accepted work and existing documentation. The outcome is enough reliable context
@@ -67,6 +67,14 @@ not prove secure behavior. Read only the context needed for the current task;
 avoid loading every reference into every worker. Resolve contradictory instructions
 at their source rather than adding another layer of instructions.
 
+Before claiming readiness, reconcile the actual instructions, README/check commands
+and local skill routes with the relevant dependency and distribution sources,
+CI/protections, chosen security/reporting controls, native capability limits and
+the existing setup record. Weigh each source against code, configuration, remote
+readback and dated observations rather than against another document. A conflict
+or unverified prerequisite stays visible as a gap; it does not become verified or
+justified not-needed because one source claims it.
+
 When work produces knowledge worth keeping, put it in the most specific existing home:
 
 | Knowledge | Home |
@@ -114,6 +122,16 @@ Installation, authentication, resource access and a successful operation are
 distinct observations. An optional dependency can still be required for a selected
 feature. Do not expand permissions merely to make a readiness indicator green.
 
+Distinguish what the product needs to run, what contributors need to author and
+verify it, and each installation or distribution route. A project may use itself
+for documented bootstrapping or dogfooding; assess that route on its real
+requirements. An instruction that makes installing the product a mandatory
+authoring step without a current, documented reason is a contradiction at its
+source. Hold the dependent work as a required gap and route it to the
+instruction's owner; do not install the product to satisfy it or silently bypass
+it. Qualify distribution claims to the route they describe: a package's payload
+exclusions, for example, say nothing about installing the whole repository.
+
 ## Operation and observability
 
 Keep the agent execution host separate from the application's runtime, accounts,
@@ -159,6 +177,13 @@ An imported observation keeps its original date and source; missing dates stay
 unknown rather than becoming today's date.
 Drafts state untested outcomes as pending, including examples with blank date fields.
 
+On reassessment, reuse the existing record, settings readback and dated proof;
+recheck only capabilities whose code, configuration, access or versions changed.
+Compare current-state claims in entry documents, such as a README's release or
+pending-cutover status, with the latest delivery readback. Correct a stale current
+claim within scope or route it to the project's actual owner, preserving dated
+historical entries. This needs no watcher or new log.
+
 Foundation establishes the relevant sources and initial checks. During accepted
 work, specification identifies affected context, implementation updates it with
 the change, and independent review checks it against the candidate and evidence.

foundation/factory-foundation/references/github.md

@@ -1,6 +1,6 @@
 # Prepare repository work tracking and delivery
 
-Revision: 0.1.9 · Updated: 2026-10-10
+Revision: 0.1.12 · Updated: 2026-10-11
 
 Inspect the actual repository, owner, default branch, existing instructions,
 checks, labels, Projects and deployment rules. Preserve established conventions.
@@ -99,6 +99,11 @@ effective workflow/token permissions, and native dependency alerts and secret
 scanning/push protection where available and appropriate. Distinguish configured,
 observed and unavailable controls; do not enable paid services or treat a scanner
 score as a security guarantee.
+When the selected private security-reporting route is GitHub private vulnerability
+reporting, read its remote setting back through the API or repository settings;
+disabled, inaccessible or unchecked state stays a visible gap. A SECURITY file
+documents a route but does not prove it is enabled. Another monitored private route,
+or a justified not-needed choice for a small private repository, remains valid.
 
 For branch policy, PR and full-check cadence, the optional three-hour batch profile,
 artifacts and preview/staging delivery, read [CI and delivery](ci-delivery.md).