Make Foundation readiness catch contradictory instructions and unverified controls #27

Problem and intended outcome

Foundation already has a capability matrix, scoped readiness, contradiction handling, remote-state readback and reuse of existing records. An assessment nevertheless accepted AIOS instructions requiring installed AIOS to develop its own source. The contradiction was later removed in AIOS PR #52; its private vulnerability-reporting route was disabled until actual readback exposed the gap.

Make Foundation produce an evidenced, proportionate readiness decision and a maintainable handoff for new and existing repositories, including Factory itself. Distinguish missing guidance, an omitted check, and an unsupported readiness claim before changing the method. More documents or checked boxes are not the outcome.

Observations and consultation — 11 October 2026

The owner requested this issue on 11 October. The fresh native Opus 5.5 Medium / Fast off consultation is COMPLETED, with its result read and assessed by Factory AgentOps. It used approval-required/plan in the Factory checkout and performed eight successful source Read calls: AGENTS, VISION, README, Foundation SKILL and engineering/context/adoption/github. Foundation/adoption were revision 0.1.10; engineering/context/github were 0.1.9 in delivered Factory 0.1.11. No implementation, acceptance tests, builds, writes or external calls were performed; no requests or child work remained pending. This was source consultation, not independent review of a changed candidate or a readiness PASS.

The following application/installation facts were supplied by the coordinator, not reproduced by the consultant:

• Stale AIOS instructions/index/distribution/ownership could require installing the product as its own authoring method. Independent review also caught a claim that wrongly generalized npm payload exclusions to whole-repository installation; the repair qualified the installation routes. Factory uses its own methods without an AIOS authoring installation.
• Private vulnerability reporting was disabled; the coordinator enabled it and read the setting back, while the application repair added SECURITY.md. A document and an enabled remote control are different evidence.
• The application's lead could not read its private adoption record through its selected sandbox. A coordinator-verified record does not prove that lead can independently maintain it.
• Factory Project1's current README still described v0.1.0 and pending host/cutover proof after delivery. Correct stale claims of current state while preserving dated historical observations.
• Recent provider/task drift and native authentication failure are operator qualification evidence in #3, not defects that Markdown alone can repair.

Bounded method change

Make one short final consistency pass over sources relevant to the intended work: actual instructions and local skill routes, README/check commands, dependencies and distribution, CI/protections, chosen security/reporting controls, native capability limits and the existing setup record. Reuse the present readiness vocabulary; unverified evidence must stay visible and must not become verified or justified not-applicable.

Minimum targets, inside the existing portable Foundation bundle:

• foundation/factory-foundation/SKILL.md: clarify the evidence required before claiming readiness and the handoff of dependent gaps, next action and responsible role.
• references/context.md: reconcile relevant prerequisites and current claims against authoritative source/configuration and dated observations. Distinguish product features, authoring-method requirements and installation/distribution routes.
• references/adoption.md: identify the actual named maintainer (person/operator or concrete authorized role), permitted record location/portion and access limit. If the lead cannot maintain the record, retain that limitation and the real handoff; do not invent independent maintenance, copy secrets or grant broad access.
• references/github.md: when private vulnerability reporting is the chosen, appropriate repository route, require actual remote readback or a visible gap. SECURITY.md is not proof, and GitHub's feature is not a universal requirement.

Reuse engineering.md as it stands unless a concrete consistency repair is necessary. Legitimate, documented bootstrapping or dogfooding remains allowed; catch stale or unjustified mandatory authoring dependencies rather than banning all self-hosting. Routine terminology and these scoped choices need no additional owner approval.

Foundation prepares/reassesses. AgentOps owns its project's mandate, readiness and agreed upkeep, including routing concrete drift within authority. ADLC proves the changed task and updates affected sources. #3 owns actual issue/worker/decision/review/delivery coordination and recovery; this issue owns the readiness handoff into that work.

Acceptance evidence

The first seven items are accepted method behavior in six source-only scenarios, independently reviewed on the candidate below. Those scenarios do not themselves prove live GitHub/T3 controls, installation or autonomous operation. The final delivery/adoption item is now completed through the separately observed publication, installed-byte verification and explicit native reloads recorded below.

• A representative assessment catches a stale mandatory authoring self-dependency and withholds only dependent readiness, without installing the product or silently bypassing contradictory instructions. A justified, documented bootstrapping/dogfooding case is assessed on its real requirements.
• A small new repo can be ready with justified non-applicable controls and existing canonical sources; no generated document forest or optional stack is imposed.
• For a repository whose selected reporting route uses GitHub private reporting, actual remote readback supports the result; disabled, inaccessible or unchecked state stays visible. An appropriate alternative route remains possible.
• A role-inaccessible maintenance record names its actual maintainer and access limit; the assessment neither claims independent lead maintenance nor broadens permissions.
• Reassessment reuses existing records/settings, preserves unchanged proof and dates, and detects stale current Project README claims without rewriting historical evidence or adding a watcher.
• Native binding/auth/capability gaps hold only dependent readiness, retain the current task and responsible next action, and route operator behavior/proof to Prove Agent Ops across idea research, assignments and accepted backlog #3. Source edits do not claim to fix the native failure or guarantee autonomy.
• Representative positive and negative behavioral outcomes are retained and independently assessed for the actual candidate. Test decisions, not wording counts; automate deterministic facts only when useful.
• Any accepted method change passes package/unit/staging checks, final independent review, affected revision/date updates and observed qualification records. Authorized installation/adoption is separately read back; old observation dates are not refreshed by editing.

Boundaries and disposition

Triage/consultation is complete. Scoped implementation was accepted on 11 October 2026. One native-bound writer produced the six-file v0.1.12 candidate on feat/foundation-readiness-27, based on 955e9c21ad27be229f1e6763d20184ec18f9da46: commit c45286cc5691256de79eecfad38f0d247168213a, tree 8c61e4b5d01c093617aaa37b881a4edaa665db02, 59 insertions / 11 deletions. Both the candidate worktree and main were read back clean. The writer used Opus 5.5 Medium / Fast off; the pinned lead remains Codex Astra xhigh.

Direct native Claude verification passed: 8 skills / 0 metadata-link errors, 11 unit tests OK and whitespace check exit 0. Disposable Foundation staging passed; the lead independently matched every staged source and LICENSE hash to the committed bytes. Checks, staging and local commit required three individually accepted native requests, with no persistent grant. An incidental read refusal was retained. The lead caught and obtained a report-only correction of the writer's initial inaccurate zero-approval claim; source bytes and results were unchanged. This remains assisted execution.

A fresh independent Astra xhigh / Standard review completed on 11 October: PASS, no material findings. Factory AgentOps read and accepted it under the existing implementation/delivery mandate. The reviewer independently ran the checker (8 skills / 0 errors), all 11 unit tests and whitespace checks; verified the canonical patch SHA-256 c150093f04c576b2e52f95c3251a6608a1b851a7b4268ea1023f1f46c7229c9f; and matched all nine staged Foundation/LICENSE files to the commit. Its no-edit task used Auto/default, which is not proof of technical read-only isolation.

Six retained source decision outcomes:

1. Stale mandatory product installation blocks dependent authoring readiness pending instruction-owner reconciliation; documented, authorized compiler bootstrap remains valid.
2. A small CLI uses its existing sources/checks and justified not-needed deployment/database/connector controls, with no new document tree.
3. Disabled selected private reporting remains a gap; unreadable state remains unverified; SECURITY.md and old notes do not prove activation. An appropriate evidenced alternative is allowed.
4. The actual private-record operator owns that inaccessible portion; the lead maintains accessible policy and hands over sanitized changes without a broader grant.
5. Reassessment preserves original proof dates, corrects stale current version/cutover claims and reuses records/settings.
6. Native authentication failure holds dependent coordination, preserves the current task and routes the gap to an operator; no obsolete probes or claim that Markdown repairs authentication.

These are textual/source scenarios, not new remote-control or recovery experiments. No source repair was required. Writer and reviewer runs are terminal with no reported pending requests or child/background work.

The authorized operator pushed the exact commit without force after the lead's normal shell push was blocked by DNS. The lead independently read back the remote branch, commit, author/coauthor and tree, checked for an existing PR, then created and native-linked PR #28. The prepared review/evidence body was read back unchanged.

On 11 October the lead merged PR #28 through the normal GitHub merge API under the standing delivery mandate, with the expected candidate head pinned. The PR workflow passed on c45286cc5691256de79eecfad38f0d247168213a. Merge/main 078b68450ebf8f7dae15498ff6422e04c575543d has the exact independently reviewed tree 8c61e4b5d01c093617aaa37b881a4edaa665db02, preserves the original commit/attribution, and declares VERSION 0.1.12. Main CI also passed on that merge. These remote states were independently read back.

Published and installed; explicit Codex reload verified on 11 October. The operator completed the earlier tag/release hold. The lead independently read back the public v0.1.12 release, published at 08:23:18Z, with the prepared notes, source-archive links and no separate uploaded assets. Annotated tag object a02bae8c88e6ff9590bcc940702d970b2c9e8f23 targets merge 078b68450ebf8f7dae15498ff6422e04c575543d; remote and clean local main match its reviewed tree. The coordinator separately verified the downloaded official source archive and reports all 48 selected installed files in the two existing native scopes match the release after adaptation checks; only four Foundation files per scope changed.

The lead explicitly read its installed Codex Foundation SKILL.md, references/context.md, references/adoption.md and references/github.md. All are version/revision 0.1.12, updated 2026-10-11. Each full SHA-256 matches the coordinator's supplied hash, the canonical working file and the exact released Git blob. This is observed explicit loading, not automatic discovery or a Claude-side reload claim. No tests or workers were rerun.

The same PR now has a short problem/before-after/validation foreground; the complete original candidate/review/verification section is preserved inside native Markdown <details>. The lead checked for newer body changes before editing and read back the exact resulting body.

Completed and accepted — 11 October 2026. The coordinator returned and retained AIOS AgentOps' completed native Claude-scope readback: it explicitly read the same four Foundation files, verified their full hashes and 0.1.12 / 2026-10-11 headers, and ended with no pending requests or background work. Its application checkout and source were unchanged. It preserved the denied private-record boundary without retry, named the coordinator/operator as the actual private-record maintainer and kept responsibility for its own accessible project policy and sanitized handoff. Factory accepts this bounded cross-project evidence; it does not take ownership of AIOS.

Together with Factory's directly observed Codex reload, this completes explicit native adoption in the two selected scopes. The 48-file installed comparison and official archive verification remain coordinator evidence; eight installed files changed, four per scope. These are explicit reads, not automatic discovery or all-harness proof. Implementation, independent review and six source scenarios, package/unit/staging checks, exact-tree PR/main CI, authorized publication, installation and the native reload handoff are complete. Close #27 as completed under the accepted mandate; no new owner gate or source change is required.

The coordinator also corrected Project1's current README to v0.1.12 and scoped completed host/cutover evidence, retaining #3's remaining native proof and the workflow/delegation policy, with exact API readback. This resolves the stale-current-claim observation above without erasing its history. Factory AgentOps owns Factory's mandate, issue/PR evidence and ongoing follow-up; AIOS AgentOps owns its own project. The protected private installation journal stays coordinator-maintained. The lead's shell-network, tag/release/board mutation and full protection-read limits remain visible and operator-assisted. #3 stays OPEN for actual default-human decisions, uncertain launch and the remaining operator behaviors; this completed delivery does not prove unattended reliability or fix a native root cause.

Board mutation is unavailable through the lead's current GitHub connector. The last operator-supplied board state before issue closure was In progress; the coordinator owns post-closure board verification and the private journal update. Neither is claimed as the lead's independent readback. Keep the existing issue/records and native board. No new checklist file, taxonomy, registry, runtime, router, scheduler, daemon, blanket setup, extra plugin dependency or permission increase. Do not duplicate #3 or reopen completed #10/#21 work. Scheduling remains deferred; #7 retains its narrow assisted-profile closure and #5 remains parked.