4.0 KiB
4.0 KiB
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-gigabitp05-interferometerp06-polisher
Immediate Next Steps
- Use the T420
atocore-contextskill in real OpenClaw workflows- confirm the ergonomics are good
- confirm the fail-open behavior remains acceptable in practice
- 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
- Continue controlled project ingestion only where the current corpus is still
thin
- a few additional anchor docs per active project
- 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
- 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
- Keep deeper automatic runtime integration deferred until the read-only model has proven value
Trusted State Status
The first conservative trusted-state promotion pass is now complete for:
p04-gigabitp05-interferometerp06-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 first curated batch is already in.
The near-term work is now:
- strengthen retrieval quality
- add a few more anchor docs only where retrieval is still weak
- keep trusted project state concise and high-confidence
Recommended Additional Anchor Docs
p04-gigabitp05-interferometerp06-polisher
P04:
- 1 to 2 more strong study summaries
- 1 to 2 more meeting notes with actual decisions
P05:
- a couple more architecture docs
- selected vendor-response notes
- possibly one or two NX/WAVE consumer docs
P06:
- more explicit interface/schema docs if needed
- selected operations or UI docs
- a distilled non-empty operational context doc to replace an empty
_context.md
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 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.