ATOCore/docs/next-steps.md

AtoCore Next Steps

Current Position

AtoCore now has:

• canonical runtime and machine storage on Dalidou
• separated source and machine-data boundaries
• initial self-knowledge ingested into the live instance
• trusted project-state entries for AtoCore itself
• a first read-only OpenClaw integration path on the T420
• a first real active-project corpus batch for:
  • p04-gigabit
  • p05-interferometer
  • p06-polisher

This working list should be read alongside:

• master-plan-status.md

Immediate Next Steps

1. Use the T420 atocore-context skill and the new organic routing layer in real OpenClaw workflows
   • confirm auto-context feels natural
   • confirm project inference is good enough in practice
   • confirm the fail-open behavior remains acceptable in practice
2. Review retrieval quality after the first real project ingestion batch
   • check whether the top hits are useful
   • check whether trusted project state remains dominant
   • reduce cross-project competition and prompt ambiguity where needed
   • use debug-context to inspect the exact last AtoCore supplement
3. Treat the active-project full markdown/text wave as complete
   • p04-gigabit
   • p05-interferometer
   • p06-polisher
4. Define a cleaner source refresh model
   • make the difference between source truth, staged inputs, and machine store explicit
   • move toward a project source registry and refresh workflow
   • foundation now exists via project registry + per-project refresh API
   • registration policy + template + proposal + approved registration are now the normal path for new projects
5. Move to Wave 2 trusted-operational ingestion
   • curated dashboards
   • decision logs
   • milestone/current-status views
   • operational truth, not just raw project notes
6. Integrate the new engineering architecture docs into active planning, not immediate schema code
   • keep docs/architecture/engineering-knowledge-hybrid-architecture.md as the target layer model
   • keep docs/architecture/engineering-ontology-v1.md as the V1 structured-domain target
   • do not start entity/relationship persistence until the ingestion, retrieval, registry, and backup baseline feels boring and stable
7. Define backup and export procedures for Dalidou
   • exercise the new SQLite + registry snapshot path on Dalidou
   • Chroma backup or rebuild policy
   • retention and restore validation
8. Keep deeper automatic runtime integration modest until the organic read-only model has proven value

Trusted State Status

The first conservative trusted-state promotion pass is now complete for:

• p04-gigabit
• p05-interferometer
• p06-polisher

Each project now has a small set of stable entries covering:

• summary
• architecture or boundary decision
• key constraints
• current next focus

This materially improves context/build quality for project-hinted prompts.

Recommended Near-Term Project Work

The active-project full markdown/text wave is now in.

The near-term work is now:

1. strengthen retrieval quality
2. promote or refine trusted operational truth where the broad corpus is now too noisy
3. keep trusted project state concise and high-confidence
4. widen only through named ingestion waves

Recommended Next Wave Inputs

Wave 2 should emphasize trusted operational truth, not bulk historical notes.

P04:

• current status dashboard
• current selected design path
• current frame interface truth
• current next-step milestone view

P05:

• selected vendor path
• current error-budget baseline
• current architecture freeze or open decisions
• current procurement / next-action view

P06:

• current system map
• current shared contracts baseline
• current calibration procedure truth
• current July / proving roadmap view

Deferred On Purpose

• automatic write-back from OpenClaw into AtoCore
• automatic memory promotion
• reflection loop integration
• replacing OpenClaw's own memory system
• syncing the live machine DB between machines

Success Criteria For The Next Batch

The next batch is successful if:

• OpenClaw can use AtoCore naturally when context is needed
• OpenClaw can infer registered projects and call AtoCore organically for project-knowledge questions
• the active-project full corpus wave can be inspected and used concretely through auto-context, context-build, and debug-context
• OpenClaw can also register a new project cleanly before refreshing it
• existing project registrations can be refined safely before refresh when the staged source set evolves
• AtoCore answers correctly for the active project set
• retrieval surfaces the seeded project docs instead of mostly AtoCore meta-docs
• trusted project state remains concise and high confidence
• project ingestion remains controlled rather than noisy
• the canonical Dalidou instance stays stable

Long-Run Goal

The long-run target is:

• continue working normally inside PKM project stacks and Gitea repos
• let OpenClaw keep its own memory and runtime behavior
• let AtoCore supplement LLM work with stronger trusted context, retrieval, and context assembly

That means AtoCore should behave like a durable external context engine and machine-memory layer, not a replacement for normal repo work or OpenClaw memory.