diff --git a/docs/current-state.md b/docs/current-state.md index 10c6b0a..2701a25 100644 --- a/docs/current-state.md +++ b/docs/current-state.md @@ -145,6 +145,11 @@ It is important to read this staged area correctly: - register-project - update-project - refresh-project +- the helper now also supports the first organic routing layer: + - `detect-project ""` + - `auto-context "" [budget] [project]` +- OpenClaw can now default to AtoCore for project-knowledge questions without + requiring explicit helper commands from the human every time ## What Exists In Memory vs Corpus @@ -217,12 +222,15 @@ This separation is healthy: ## Immediate Next Focus -1. Use the new T420-side AtoCore skill and registration flow in real OpenClaw workflows -2. Keep the new engineering-knowledge architecture docs as implementation guidance while avoiding premature schema work -3. Tighten retrieval quality for the newly seeded active projects -4. Define the first broader AtoVault/AtoDrive ingestion batches -5. Add backup/export strategy for Dalidou machine state -6. Only later consider deeper automatic OpenClaw integration or write-back +1. Use the new T420-side organic routing layer in real OpenClaw workflows +2. Keep tightening retrieval quality for the newly seeded active projects +3. Define the first broader AtoVault/AtoDrive ingestion batches +4. Keep the new engineering-knowledge architecture docs as implementation guidance while avoiding premature schema work +5. Expand the boring operations baseline: + - restore validation + - Chroma rebuild / backup policy + - retention +6. Only later consider write-back, reflection, or deeper autonomous behaviors See also: diff --git a/docs/master-plan-status.md b/docs/master-plan-status.md index 3a89a6f..68fc60f 100644 --- a/docs/master-plan-status.md +++ b/docs/master-plan-status.md @@ -63,6 +63,7 @@ These are the current practical priorities. 1. Finish practical OpenClaw integration - make the helper lifecycle feel natural in daily use + - use the new organic routing layer for project-knowledge questions - confirm fail-open behavior remains acceptable - keep AtoCore clearly additive 2. Tighten retrieval quality diff --git a/docs/next-steps.md b/docs/next-steps.md index 99067ac..6707db6 100644 --- a/docs/next-steps.md +++ b/docs/next-steps.md @@ -20,8 +20,10 @@ This working list should be read alongside: ## Immediate Next Steps -1. Use the T420 `atocore-context` skill in real OpenClaw workflows - - confirm the ergonomics are good +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 @@ -45,8 +47,8 @@ This working list should be read alongside: - exercise the new SQLite + registry snapshot path on Dalidou - Chroma backup or rebuild policy - retention and restore validation -7. Keep deeper automatic runtime integration deferred until the read-only model - has proven value +7. Keep deeper automatic runtime integration modest until the organic read-only + model has proven value ## Trusted State Status @@ -111,6 +113,8 @@ P06: 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 - 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 diff --git a/docs/openclaw-integration-contract.md b/docs/openclaw-integration-contract.md index ef71543..e57f789 100644 --- a/docs/openclaw-integration-contract.md +++ b/docs/openclaw-integration-contract.md @@ -20,10 +20,13 @@ The first safe integration foundation now exists on the T420 workspace: - `health` - `project-state` - `query` + - `detect-project` + - `auto-context` - fail-open fallback when AtoCore is unavailable -This means the network and workflow foundation is working, even though deeper -automatic integration into OpenClaw runtime behavior is still deferred. +This means the network and workflow foundation is working, and the first +organic routing layer now exists, even though deeper autonomous integration +into OpenClaw runtime behavior is still deferred. ## Integration Principles @@ -43,6 +46,7 @@ OpenClaw may use AtoCore for: - context building for contextual prompts - retrieval/query support - project-state lookup when a project is detected +- automatic project-context augmentation for project-knowledge questions OpenClaw should not yet use AtoCore for: @@ -76,6 +80,8 @@ The current helper script exposes: - `stats` - `projects` - `project-template` +- `detect-project ` +- `auto-context [budget] [project]` - `propose-project ...` - `register-project ...` - `update-project ...` @@ -117,10 +123,17 @@ Recommended first behavior: ## Suggested Usage Pattern 1. OpenClaw receives a user request -2. OpenClaw decides whether the request is contextual enough to query AtoCore -3. If yes, OpenClaw calls AtoCore -4. If AtoCore returns usable context, OpenClaw includes it -5. If AtoCore fails or returns nothing useful, OpenClaw proceeds normally +2. If the prompt looks like project knowledge, OpenClaw should try: + - `auto-context "" 3000` +3. If the prompt is clearly asking for trusted current truth, OpenClaw should + prefer: + - `project-state ` +4. If the user explicitly asked for source refresh or ingestion, OpenClaw + should use: + - `refresh-project ` +5. If AtoCore returns usable context, OpenClaw includes it +6. If AtoCore fails, returns `no_project_match`, or is unavailable, OpenClaw + proceeds normally ## Deferred Work