Add project registry update flow

docs/current-state.md

@@ -43,6 +43,7 @@ now includes a first curated ingestion batch for the active projects.
   - template
   - proposal preview
   - approved registration
+  - safe update of existing project registrations
   - refresh
 - env-driven storage and deployment paths
 - Dalidou Docker deployment foundation
@@ -98,9 +99,9 @@ The Dalidou instance already contains:
 Current live stats after the latest documentation sync and active-project ingest
 passes:
 
-- `source_documents`: 35
-- `source_chunks`: 560
-- `vectors`: 560
+- `source_documents`: 36
+- `source_chunks`: 568
+- `vectors`: 568
 
 The broader long-term corpus is still not fully populated yet. Wider project and
 vault ingestion remains a deliberate next step rather than something already
@@ -162,10 +163,19 @@ The source refresh model now has a concrete foundation in code:
 - the API can return a registration template
 - the API can preview a registration without mutating state
 - the API can persist an approved registration
+- the API can update an existing registered project without changing its canonical id
 - the API can refresh one registered project at a time
 
 This lifecycle is now coherent end to end for normal use.
 
+The first live update pass on an existing registered project has also now been
+verified against `p04-gigabit`:
+
+- the registration description can be updated safely
+- the canonical project id remains unchanged
+- refresh still behaves cleanly after the update
+- `context/build` still returns useful project-specific context afterward
+
 ## Reliability Baseline
 
 The runtime has now been hardened in a few practical ways:

docs/next-steps.md

@@ -104,6 +104,8 @@ 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

docs/project-registration-policy.md

@@ -2,7 +2,8 @@
 
 ## Purpose
 
-This document defines the normal path for adding a new project to AtoCore.
+This document defines the normal path for adding a new project to AtoCore and
+for safely updating an existing registration later.
 
 The goal is to make `register + refresh` the standard workflow instead of
 relying on long custom ingestion prompts every time.
@@ -18,6 +19,13 @@ Registration means:
 - the staged source roots for that project are defined
 - AtoCore and OpenClaw can later refresh that project consistently
 
+Updating a project means:
+
+- aliases can be corrected or expanded
+- the short registry description can be improved
+- ingest roots can be adjusted deliberately
+- the canonical project id remains stable
+
 ## Required Fields
 
 Each project registry entry must include:
@@ -82,6 +90,17 @@ For a new project:
 7. verify retrieval and context quality
 8. only later promote stable facts into Trusted Project State
 
+For an existing registered project:
+
+1. inspect the current entry with:
+   - `GET /projects`
+   - or `atocore.sh projects`
+2. update the registration if aliases, description, or roots need refinement:
+   - `PUT /projects/{id}`
+3. verify the updated entry
+4. refresh the project again
+5. verify retrieval and context quality did not regress
+
 ## What Not To Do
 
 Do not:
@@ -106,4 +125,5 @@ Other lifecycle endpoints:
 
 - `POST /projects/proposal`
 - `POST /projects/register`
+- `PUT /projects/{id}`
 - `POST /projects/{id}/refresh`