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`

## Immediate Next Steps

1. Use the T420 `atocore-context` skill in real OpenClaw workflows
   - confirm the ergonomics are good
   - 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
3. Continue controlled project ingestion only where the current corpus is still
   thin
   - a few additional anchor docs per active project
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
5. Define backup and export procedures for Dalidou
   - SQLite snapshot/backup strategy
   - Chroma backup or rebuild policy
6. 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-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 first curated batch is already in.

The near-term work is now:

1. strengthen retrieval quality
2. add a few more anchor docs only where retrieval is still weak
3. keep trusted project state concise and high-confidence

## Recommended Additional Anchor Docs

1. `p04-gigabit`
2. `p05-interferometer`
3. `p06-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
- 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.