Lessons Learned

AIWikis.org is a live dogfooding project. It tests LLM Wiki, UAIX, source-governance, source-package, and agent-handoff recommendations against real implementation work.

What Worked

• Building the source manifest early made source attribution concrete.
• Keeping AIWikis theme/plugin/release evidence separate from LlmWikis and UAIX source-published packages clarified ownership.
• Dogfood notes forced recommendation changes to be explicit instead of hidden in implementation churn.

What Was Harder Than Expected

• The source list is broad enough that source roles must be named carefully.
• Starter-package guidance needs a strong ownership label or a consumer site can accidentally look like the upstream publisher.
• Discovery routes need both WordPress rewrite handling and static deployment fallback notes.
• The first package pass made AIWikis look like the owner of an AIWikis-branded starter ZIP. Package dogfood has to inspect artifact names, routes, and download labels, not only ZIP contents.
• Local observations of UAIX, LlmWikis, and Protocol5 distributable packages should be recorded as source evidence without copying those ZIP, NuGet, or starter payloads into AIWikis public packages.
• Processed archives need a final memory home. Keeping them only in source-site dead archives makes the deep reasoning hard to search later, so AIWikis now pulls reviewed UAIX and LlmWikis archive files into raw/system-archives/ and publishes only safe summaries.
• The deep memory layer needs its own public-safe explanation. Without a Deep Cognitive Archive page, future agents can confuse raw archives, public pages, and compact .uai handoff packets.
• The Project Handoff strategy needs an executable export loop. AIWikis had compact .uai files and reviewed wiki nodes, but no script proved that selected wiki memory could generate a compact handoff packet. That gap is now tracked as a recommendation and checked in local tooling.
• A processed file still needs visible closure. The 2026-04-30 UAIX reports showed that raw archive copies and transfer manifests are not enough; humans need an outcome ledger that says what changed, what was deferred or blocked, and where the reviewed documentation can be viewed.
• Empty memory skeletons are not enough for adoption. The UAIX AI Memory Wizard became more useful when it generated operating protocol decisions: source authority, memory update timing, evidence ledger, conflict handling, testing, deployment, review, risk, and rollback.
• A roadmap page is part of the memory system, not just project management. Without a current/next/later/blocked surface, future agents have to infer priorities from changelog and recommendation fragments.
• Generated source-file pages need human-scale source-system guides beside them. The guides explain what UAIX.org, LLMWikis.org, Protocol5.com, and ɩ.com / JustAnIota.com each own, how AIWikis preserves evidence, when to update memory, and which claims must stay out of scope.
• Cross-site memory needs an atlas and an operations playbook. The atlas prevents authority drift across UAIX.org, LLMWikis.org, Protocol5.com, ɩ.com / JustAnIota.com, and AIWikis.org; the playbook prevents future agents from updating pages without refreshing source sync, reports, handoff export, package evidence, or support-boundary state.
• Implementation-package sources need their own memory boundary. Protocol5 can be fully indexed for UAI .NET package and route evidence while UAI-1 standards authority still routes to UAIX.org.
• Preserved source memory needs a visible source home. JustAnIota showed that intake manifests and wiki nodes are not enough if the home page and generated route split do not list ɩ.com / JustAnIota.com as its own source system.
• A memory system needs coverage and claim registers. The coverage matrix tells agents whether AIWikis has enough local evidence; the claim register stops local dogfood evidence from turning into certification, hosted validation, automatic sync, or source-site authority language.

What Remains Unresolved

• Whether AIWikis should publish a downloadable source manifest.
• Whether public Markdown pages should stay hand-authored or eventually be generated from reviewed source-side wiki nodes.
• How often public dogfood observations should promote into accepted recommendations.
• Which .uai files belong in LlmWikis starter bundles versus UAIX Project Handoff exports.
• How much of the system archive should become public summary pages versus source-side wiki nodes only.
• Which deep-memory node fields should stay AIWikis-local and which, if any, should be proposed upstream to LLMWikis or UAIX.
• Whether the local Project Handoff export should remain release evidence or later become a public-safe download after source authority and support boundaries are reviewed.
• Whether future intake outcomes should stay on one rolling ledger page or become dated child pages generated from reviewed source-side log nodes.
• Whether AIWikis should turn observed UAIX wizard protocol choices into a public dogfood checklist for projects that combine compact UAI memory packets with deeper LLM Wiki memory.
• Whether the source memory guides should later gain dated child pages for major UAIX, LLMWikis, Protocol5, or JustAnIota source-system changes.
• Whether every new source-system intake preservation needs an immediate home-page, source-guide, coverage, claim-boundary, and generated-route checklist.
• Whether the Cross-Site Memory Atlas should later become a machine-readable claim-routing matrix for agents.
• Whether the Memory Coverage Matrix and Claim Boundary Register should eventually be emitted as machine-readable JSON for agent checks.