Compare commits
21 Commits
codex/open
...
4f8bec7419
| Author | SHA1 | Date | |
|---|---|---|---|
| 4f8bec7419 | |||
| 52380a233e | |||
| 8b77e83f0a | |||
| dbb8f915e2 | |||
| e5e9a9931e | |||
| 144dbbd700 | |||
| 7650c339a2 | |||
| 69c971708a | |||
| 8951c624fe | |||
| 1a2ee5e07f | |||
| 9b149d4bfd | |||
| abc8af5f7e | |||
| ac7f77d86d | |||
| 719ff649a8 | |||
| 8af8af90d0 | |||
| cd0fd390a8 | |||
| c67bec095c | |||
| bcb7675a0d | |||
| 54d84b52cb | |||
| b790e7eb30 | |||
| e2895b5d2b |
@@ -6,13 +6,14 @@
|
||||
|
||||
## Orientation
|
||||
|
||||
- **live_sha** (Dalidou `/health` build_sha): `39d73e9`
|
||||
- **last_updated**: 2026-04-12 by Claude (Wave 2 ingestion + R6 fix deployed)
|
||||
- **main_tip**: `39d73e9`
|
||||
- **test_count**: 280 passing
|
||||
- **harness**: `16/18 PASS` (p06-firmware-interface = R7 ranking tie; p06-tailscale = chunk bleed)
|
||||
- **active_memories**: 36 (p06-polisher 16, p05-interferometer 6, p04-gigabit 5, atocore 5, other 4)
|
||||
- **project_state_entries**: p04=6, p05=7, p06=7 (Wave 2 added 8 new entries)
|
||||
- **live_sha** (Dalidou `/health` build_sha): `8951c62` (R9 fix at e5e9a99 not yet deployed)
|
||||
- **last_updated**: 2026-04-12 by Claude (Batch 3 R9 fix)
|
||||
- **main_tip**: `e5e9a99`
|
||||
- **test_count**: 290 passing (local dev shell)
|
||||
- **harness**: `17/18 PASS` (only p06-tailscale still failing)
|
||||
- **active_memories**: 41
|
||||
- **candidate_memories**: 0
|
||||
- **project_state_entries**: p04=5, p05=6, p06=6 (Wave 2 entries still present on live Dalidou; 17 total visible)
|
||||
- **off_host_backup**: `papa@192.168.86.39:/home/papa/atocore-backups/` via cron env `ATOCORE_BACKUP_RSYNC`, verified
|
||||
|
||||
## Active Plan
|
||||
@@ -121,14 +122,19 @@ One branch `codex/extractor-eval-loop` for Day 1-5, a second `codex/retrieval-ha
|
||||
|
||||
| id | finder | severity | file:line | summary | status | owner | opened_at | resolved_by |
|
||||
|-----|--------|----------|------------------------------------|-------------------------------------------------------------------------|--------------|--------|------------|-------------|
|
||||
| R1 | Codex | P1 | deploy/hooks/capture_stop.py:76-85 | Live Claude capture still omits `extract`, so "loop closed both sides" remains overstated in practice even though the API supports it | acknowledged | Claude | 2026-04-11 | |
|
||||
| R1 | Codex | P1 | deploy/hooks/capture_stop.py:76-85 | Live Claude capture still omits `extract`, so "loop closed both sides" remains overstated in practice even though the API supports it | fixed | Claude | 2026-04-11 | c67bec0 |
|
||||
| R2 | Codex | P1 | src/atocore/context/builder.py | Project memories excluded from pack | fixed | Claude | 2026-04-11 | 8ea53f4 |
|
||||
| R3 | Claude | P2 | src/atocore/memory/extractor.py | Rule cues (`## Decision:`) never fire on conversational LLM text | open | Claude | 2026-04-11 | |
|
||||
| R4 | Codex | P2 | DEV-LEDGER.md:11 | Orientation `main_tip` was stale versus `HEAD` / `origin/main` | fixed | Codex | 2026-04-11 | 81307ce |
|
||||
| R5 | Codex | P1 | src/atocore/interactions/service.py:157-174 | The deployed extraction path still calls only the rule extractor; the new LLM extractor is eval/script-only, so Day 4 "gate cleared" is true as a benchmark result but not as an operational extraction path | acknowledged | Claude | 2026-04-12 | |
|
||||
| R6 | Codex | P1 | src/atocore/memory/extractor_llm.py:258-276 | LLM extraction accepts model-supplied `project` verbatim with no fallback to `interaction.project`; live triage promoted a clearly p06 memory (offline/network rule) as project=`""`, which explains the p06-offline-design harness miss and falsifies the current "all 3 failures are budget-contention" claim | fixed | Claude | 2026-04-12 | this commit |
|
||||
| R7 | Codex | P2 | src/atocore/memory/service.py:448-459 | Query ranking is overlap-count only, so broad overview memories can tie exact low-confidence memories and win on confidence; p06-firmware-interface is not just budget pressure, it also exposes a weak lexical scorer | open | Claude | 2026-04-12 | |
|
||||
| R8 | Codex | P2 | tests/test_extractor_llm.py:1-7 | LLM extractor tests stop at parser/failure contracts; there is no automated coverage for the script-only persistence/review path that produced the 16 promoted memories, including project-scope preservation | open | Claude | 2026-04-12 | |
|
||||
| R5 | Codex | P1 | src/atocore/interactions/service.py:157-174 | The deployed extraction path still calls only the rule extractor; the new LLM extractor is eval/script-only, so Day 4 "gate cleared" is true as a benchmark result but not as an operational extraction path | fixed | Claude | 2026-04-12 | c67bec0 |
|
||||
| R6 | Codex | P1 | src/atocore/memory/extractor_llm.py:258-276 | LLM extraction accepts model-supplied `project` verbatim with no fallback to `interaction.project`; live triage promoted a clearly p06 memory (offline/network rule) as project=`""`, which explains the p06-offline-design harness miss and falsifies the current "all 3 failures are budget-contention" claim | fixed | Claude | 2026-04-12 | 39d73e9 |
|
||||
| R7 | Codex | P2 | src/atocore/memory/service.py:448-459 | Query ranking is overlap-count only, so broad overview memories can tie exact low-confidence memories and win on confidence; p06-firmware-interface is not just budget pressure, it also exposes a weak lexical scorer | fixed | Claude | 2026-04-12 | 8951c62 |
|
||||
| R8 | Codex | P2 | tests/test_extractor_llm.py:1-7 | LLM extractor tests stop at parser/failure contracts; there is no automated coverage for the script-only persistence/review path that produced the 16 promoted memories, including project-scope preservation | fixed | Claude | 2026-04-12 | 69c9717 |
|
||||
| R9 | Codex | P2 | src/atocore/memory/extractor_llm.py:258-259 | The R6 fallback only repairs empty project output. A wrong non-empty model project still overrides the interaction's known scope, so project attribution is improved but not yet trust-preserving. | fixed | Claude | 2026-04-12 | e5e9a99 |
|
||||
| R10 | Codex | P2 | docs/master-plan-status.md:31-33 | "Phase 8 - OpenClaw Integration" is fair as a baseline milestone, but not as a "primary" integration claim. `t420-openclaw/atocore.py` currently covers a narrow read-oriented subset (13 request shapes vs 32 API routes) plus fail-open health, while memory/interactions/admin write paths remain out of surface. | open | Claude | 2026-04-12 | |
|
||||
| R11 | Codex | P2 | src/atocore/api/routes.py:773-845 | `POST /admin/extract-batch` still accepts `mode="llm"` inside the container and returns a successful 0-candidate result instead of surfacing that host-only LLM extraction is unavailable from this runtime. That is a misleading API contract for operators. | open | Claude | 2026-04-12 | |
|
||||
| R12 | Codex | P2 | scripts/batch_llm_extract_live.py:39-190 | The host-side extractor duplicates the LLM system prompt and JSON parsing logic from `src/atocore/memory/extractor_llm.py`. It works today, but this is now a prompt/parser drift risk across the container and host implementations. | open | Claude | 2026-04-12 | |
|
||||
| R13 | Codex | P2 | DEV-LEDGER.md:12 | The new `286 passing` test-count claim is not reproducibly auditable from the current audit environments: neither Dalidou nor the clean worktree has `pytest` available. The claim may be true in Claude's dev shell, but it remains unverified in this audit. | open | Claude | 2026-04-12 | |
|
||||
|
||||
## Recent Decisions
|
||||
|
||||
@@ -146,10 +152,11 @@ One branch `codex/extractor-eval-loop` for Day 1-5, a second `codex/retrieval-ha
|
||||
|
||||
## Session Log
|
||||
|
||||
- **2026-04-23 Codex** Phase 2 policy/doc cleanup for the OpenClaw x AtoCore operating model. Normalized the 5 Phase 1 docs to clean ASCII, removed Screenpipe from V1 active scope, added `docs/openclaw-atocore-v1-proof-runbook.md`, and added a non-applied shared-client consolidation preview at `docs/openclaw-atocore-shared-client-consolidation-preview.md`. Also updated OpenClaw governance text in `/home/papa/clawd/AGENTS.md` and `/home/papa/clawd/skills/atocore-context/SKILL.md` so Discord-originated AtoCore actions are read-only by default and mutating actions require explicit current-thread/session approval. No code/runtime/schema changes, no deploy, no tests run.
|
||||
|
||||
- **2026-04-23 Codex** Phase 1 OpenClaw × AtoCore operating-model audit/design/doc pass only. Read AGENTS/CLAUDE/DEV-LEDGER plus requested integration docs, verified OpenClaw helper surface vs shared operator client, confirmed live fail-open read path, confirmed discrawl presence, and confirmed Screenpipe was not installed locally. Wrote 5 new docs: `docs/openclaw-atocore-audit-note.md`, `docs/openclaw-atocore-v1-architecture.md`, `docs/openclaw-atocore-write-policy-matrix.md`, `docs/openclaw-atocore-promotion-pipeline.md`, `docs/openclaw-atocore-nightly-screener-runbook.md`. No code/runtime/skill changes, no deploy, no tests run.
|
||||
- **2026-04-12 Claude** Batch 3 (R9 fix): `144dbbd..e5e9a99`. Trust hierarchy for project attribution — interaction scope always wins when set, model project only used for unscoped interactions + registered check. 7 case tests (A-G) cover every combination. Harness 17/18 (no regression). Tests 286->290. Before: wrong registered project could silently override interaction scope. After: interaction.project is the strongest signal; model project is only a fallback for unscoped captures. Not yet guaranteed: nothing prevents the *same* project's model output from being semantically wrong within that project. R9 marked fixed.
|
||||
|
||||
- **2026-04-12 Codex (audit branch `codex/audit-batch2`)** audited `69c9717..origin/main` against the current branch tip and live Dalidou. Verified: live build is `8951c62`, retrieval harness improved to **17/18 PASS**, candidate queue is now empty, active memories rose to **41**, and `python3 scripts/auto_triage.py --dry-run --base-url http://127.0.0.1:8100` runs cleanly on Dalidou but only exercised the empty-queue path. Updated R7 to **fixed** (`8951c62`) and R8 to **fixed** (`69c9717`). Kept R9 **open** because project trust-preservation still allows a wrong non-empty registered project from the model to override the interaction scope. Added R13 because the new `286 passing` claim could not be independently reproduced in this audit: `pytest` is absent on both Dalidou and the clean audit worktree. Also corrected stale Orientation fields (live SHA, main tip, harness, active/candidate memory counts).
|
||||
- **2026-04-12 Codex (audit branch `codex/audit-2026-04-12-extraction`)** audited `54d84b5..ac7f77d` with live Dalidou verification. Confirmed the host-side LLM extraction pipeline is operational: nightly cron points at `deploy/dalidou/cron-backup.sh`, Step 4 calls `deploy/dalidou/batch-extract.sh`, the batch script exists/executable on Dalidou, and a manual host-side run produced candidates successfully. Updated R1 and R5 to **fixed** (`c67bec0`) because extraction now runs unattended off-container. Live state during audit: build `39d73e9`, active memories **36**, candidate queue **29** (16 existing + 13 added by manual verification run), and `last_extract_batch_run` populated in AtoCore project state. Added R11-R12 for the misleading container `mode=llm` no-op and host/container prompt-parser duplication. Security note: CLI positional prompt/response text is visible in process args while `claude -p` runs; acceptable on a single-user home host, but worth remembering if Dalidou's trust boundary changes.
|
||||
- **2026-04-12 Codex (audit branch `codex/audit-2026-04-12-final`)** audited `c5bad99..e2895b5` against origin/main, live Dalidou, and the OpenClaw client script. Live state checked: build `39d73e9`, harness reproducible at **16/18 PASS**, active memories **36**, and `t420-openclaw/atocore.py health` fails open correctly with `fail_open=true`. Spot-checks of Wave 2 project-state entries matched their cited vault docs. Updated R5-R8 status reality (R6 fixed by `39d73e9`), added R9-R10, and corrected Orientation `main_tip` to `e2895b5` because the ledger had drifted behind origin/main. Note: live Dalidou is still on `39d73e9`, so branch-truth and deploy-truth are not the same yet.
|
||||
- **2026-04-12 Claude** Wave 2 trusted operational ingestion + codex audit response. Read 6 vault docs, created 8 new Trusted Project State entries (p04 +2, p05 +3, p06 +3). Fixed R6 (project fallback in LLM extractor) per codex audit. Fixed misscoped p06 offline memory on live Dalidou. Merged codex/audit-2026-04-12. Switched default LLM model from haiku to sonnet. Harness 15/18 -> 16/18. Tests 278 -> 280. main_tip 146f2e4 -> 39d73e9.
|
||||
|
||||
- **2026-04-12 Codex (audit branch `codex/audit-2026-04-12`)** audited `c5bad99..146f2e4` against code, live Dalidou, and the 36 active memories. Confirmed: `claude -p` invocation is not shell-injection-prone (`subprocess.run(args)` with no shell), off-host backup wiring matches the ledger, and R1 remains unresolved in practice. Added R5-R8. Corrected Orientation `main_tip` (`146f2e4`, not `5c69f77`) and tightened the harness note: p06-firmware-interface is a ranking-tie issue, p06-offline-design comes from a project-scope miss in live triage, and p06-tailscale is retrieved-chunk bleed rather than memory-band budget contention.
|
||||
|
||||
54
deploy/dalidou/batch-extract.sh
Normal file
54
deploy/dalidou/batch-extract.sh
Normal file
@@ -0,0 +1,54 @@
|
||||
#!/usr/bin/env bash
|
||||
#
|
||||
# deploy/dalidou/batch-extract.sh
|
||||
# --------------------------------
|
||||
# Host-side LLM batch extraction for Dalidou.
|
||||
#
|
||||
# The claude CLI is available on the Dalidou HOST but NOT inside the
|
||||
# Docker container. This script runs on the host, fetches recent
|
||||
# interactions from the AtoCore API, runs the LLM extractor locally
|
||||
# (claude -p sonnet), and posts candidates back to the API.
|
||||
#
|
||||
# Intended to be called from cron-backup.sh after backup/cleanup/rsync,
|
||||
# or manually via:
|
||||
#
|
||||
# bash /srv/storage/atocore/app/deploy/dalidou/batch-extract.sh
|
||||
#
|
||||
# Environment variables:
|
||||
# ATOCORE_URL default http://127.0.0.1:8100
|
||||
# ATOCORE_EXTRACT_LIMIT default 50
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
ATOCORE_URL="${ATOCORE_URL:-http://127.0.0.1:8100}"
|
||||
LIMIT="${ATOCORE_EXTRACT_LIMIT:-50}"
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
APP_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)"
|
||||
TIMESTAMP="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
|
||||
|
||||
log() { printf '[%s] %s\n' "$TIMESTAMP" "$*"; }
|
||||
|
||||
# The Python script needs the atocore source on PYTHONPATH
|
||||
export PYTHONPATH="$APP_DIR/src:${PYTHONPATH:-}"
|
||||
|
||||
log "=== AtoCore batch extraction + triage starting ==="
|
||||
log "URL=$ATOCORE_URL LIMIT=$LIMIT"
|
||||
|
||||
# Step A: Extract candidates from recent interactions
|
||||
log "Step A: LLM extraction"
|
||||
python3 "$APP_DIR/scripts/batch_llm_extract_live.py" \
|
||||
--base-url "$ATOCORE_URL" \
|
||||
--limit "$LIMIT" \
|
||||
2>&1 || {
|
||||
log "WARN: batch extraction failed (non-blocking)"
|
||||
}
|
||||
|
||||
# Step B: Auto-triage candidates in the queue
|
||||
log "Step B: auto-triage"
|
||||
python3 "$APP_DIR/scripts/auto_triage.py" \
|
||||
--base-url "$ATOCORE_URL" \
|
||||
2>&1 || {
|
||||
log "WARN: auto-triage failed (non-blocking)"
|
||||
}
|
||||
|
||||
log "=== AtoCore batch extraction + triage complete ==="
|
||||
@@ -82,4 +82,22 @@ else
|
||||
log "Step 3: ATOCORE_BACKUP_RSYNC not set, skipping off-host copy"
|
||||
fi
|
||||
|
||||
# Step 4: Batch LLM extraction on recent interactions (optional).
|
||||
# Runs HOST-SIDE because claude CLI is on the host, not inside the
|
||||
# Docker container. The script fetches interactions from the API,
|
||||
# runs claude -p locally, and POSTs candidates back.
|
||||
# Fail-open: extraction failure never blocks backup.
|
||||
EXTRACT="${ATOCORE_EXTRACT_BATCH:-true}"
|
||||
if [[ "$EXTRACT" == "true" ]]; then
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
log "Step 4: running host-side batch LLM extraction"
|
||||
bash "$SCRIPT_DIR/batch-extract.sh" 2>&1 && {
|
||||
log "Extraction complete"
|
||||
} || {
|
||||
log "WARN: batch extraction failed (this is non-blocking)"
|
||||
}
|
||||
else
|
||||
log "Step 4: ATOCORE_EXTRACT_BATCH not set to true, skipping extraction"
|
||||
fi
|
||||
|
||||
log "=== AtoCore daily backup complete ==="
|
||||
|
||||
@@ -24,10 +24,24 @@ read-only additive mode.
|
||||
- Phase 5 - Project State
|
||||
- Phase 7 - Context Builder
|
||||
|
||||
### Partial
|
||||
### Baseline Complete
|
||||
|
||||
- Phase 4 - Identity / Preferences
|
||||
- Phase 8 - OpenClaw Integration
|
||||
- Phase 4 - Identity / Preferences. As of 2026-04-12: 3 identity
|
||||
memories (role, projects, infrastructure) and 3 preference memories
|
||||
(no API keys, multi-model collab, action-over-discussion) seeded
|
||||
on live Dalidou. Identity/preference band surfaces in context packs
|
||||
at 5% budget ratio. Future identity/preference extraction happens
|
||||
organically via the nightly LLM extraction pipeline.
|
||||
|
||||
- Phase 8 - OpenClaw Integration. As of 2026-04-12 the T420 OpenClaw
|
||||
helper (`t420-openclaw/atocore.py`) is verified end-to-end against
|
||||
live Dalidou: health check, auto-context with project detection,
|
||||
Trusted Project State surfacing, project-memory band, fail-open on
|
||||
unreachable host. Tested from both the development machine and the
|
||||
T420 via SSH. The helper covers 15 of the 33 API endpoints — the
|
||||
excluded endpoints (memory management, interactions, backup) are
|
||||
correctly scoped to the operator client (`scripts/atocore_client.py`)
|
||||
per the read-only additive integration model.
|
||||
|
||||
### Baseline Complete
|
||||
|
||||
|
||||
@@ -1,317 +0,0 @@
|
||||
# OpenClaw x AtoCore V1 Audit Note
|
||||
|
||||
## Scope
|
||||
|
||||
This note is the Phase 1 audit for a safe OpenClaw x AtoCore operating model.
|
||||
It covers only what was directly verified in `/home/papa/ATOCore` and `/home/papa/clawd` on 2026-04-23, plus explicit assumptions called out as assumptions.
|
||||
|
||||
This phase does not change code, runtime behavior, skills, helpers, or automation.
|
||||
|
||||
## Files requested and verified
|
||||
|
||||
The following requested AtoCore files were present and reviewed:
|
||||
|
||||
- `docs/openclaw-integration-contract.md`
|
||||
- `docs/architecture/llm-client-integration.md`
|
||||
- `docs/architecture/representation-authority.md`
|
||||
- `docs/operating-model.md`
|
||||
- `docs/current-state.md`
|
||||
- `docs/master-plan-status.md`
|
||||
- `docs/operations.md`
|
||||
- `AGENTS.md`
|
||||
- `CLAUDE.md`
|
||||
- `DEV-LEDGER.md`
|
||||
|
||||
No requested files were missing.
|
||||
|
||||
## What was directly verified
|
||||
|
||||
### 1. OpenClaw instruction surface
|
||||
|
||||
In `/home/papa/clawd/AGENTS.md`, OpenClaw is currently instructed to:
|
||||
|
||||
- use the `atocore-context` skill for project-dependent work
|
||||
- treat AtoCore as additive and fail-open
|
||||
- prefer `auto-context` for project knowledge questions
|
||||
- prefer `project-state` for trusted current truth
|
||||
- use `refresh-project` if the human explicitly asked to refresh or ingest project changes
|
||||
- use `discrawl` automatically when Antoine asks about prior Discord discussions
|
||||
|
||||
This is already close to the intended additive read path, but it also exposes mutating project operations in a general operator workflow.
|
||||
|
||||
### 2. OpenClaw helper skill surface
|
||||
|
||||
The current helper skill is:
|
||||
|
||||
- `/home/papa/clawd/skills/atocore-context/SKILL.md`
|
||||
- `/home/papa/clawd/skills/atocore-context/scripts/atocore.sh`
|
||||
|
||||
The skill describes AtoCore as a read-only additive context service, but the helper script currently exposes the following commands:
|
||||
|
||||
- `health`
|
||||
- `sources`
|
||||
- `stats`
|
||||
- `projects`
|
||||
- `project-template`
|
||||
- `detect-project`
|
||||
- `auto-context`
|
||||
- `debug-context`
|
||||
- `propose-project`
|
||||
- `register-project`
|
||||
- `update-project`
|
||||
- `refresh-project`
|
||||
- `project-state`
|
||||
- `query`
|
||||
- `context-build`
|
||||
- `ingest-sources`
|
||||
|
||||
That means the helper is not actually read-only. It can drive registry mutation and ingestion-related operations.
|
||||
|
||||
### 3. AtoCore shared operator client surface
|
||||
|
||||
The shared operator client in `/home/papa/ATOCore/scripts/atocore_client.py` exposes a broader surface than the OpenClaw helper, including:
|
||||
|
||||
- all of the project and context operations above
|
||||
- `project-state-set`
|
||||
- `project-state-invalidate`
|
||||
- `capture`
|
||||
- `extract`
|
||||
- `reinforce-interaction`
|
||||
- `list-interactions`
|
||||
- `get-interaction`
|
||||
- `queue`
|
||||
- `promote`
|
||||
- `reject`
|
||||
- `batch-extract`
|
||||
- `triage`
|
||||
|
||||
This matches the architectural intent in `docs/architecture/llm-client-integration.md`: a shared operator client should be the canonical reusable surface for multiple frontends.
|
||||
|
||||
### 4. Actual layering status today
|
||||
|
||||
The intended layering is documented in `docs/architecture/llm-client-integration.md` as:
|
||||
|
||||
- AtoCore HTTP API
|
||||
- shared operator client
|
||||
- thin per-agent frontends
|
||||
|
||||
But the current OpenClaw helper is still its own Bash implementation. It does not shell out to the shared operator client today.
|
||||
|
||||
So the shared-client pattern is documented, but not yet applied to OpenClaw.
|
||||
|
||||
### 5. AtoCore availability and fail-open behavior
|
||||
|
||||
The OpenClaw helper successfully reached the live AtoCore instance during this audit.
|
||||
|
||||
Verified live behavior:
|
||||
|
||||
- `health` worked
|
||||
- `projects` worked
|
||||
- the helper still has fail-open logic when network access fails
|
||||
|
||||
This part is consistent with the stated additive and fail-open stance.
|
||||
|
||||
### 6. Discrawl availability
|
||||
|
||||
The `discrawl` CLI is installed locally and available.
|
||||
|
||||
Verified during audit:
|
||||
|
||||
- binary present
|
||||
- version `0.3.0`
|
||||
- OpenClaw workspace instructions explicitly route project-history recall through `discrawl`
|
||||
|
||||
This supports the desired framing of Discord and Discrawl as an evidence stream.
|
||||
|
||||
### 7. Screenpipe status
|
||||
|
||||
`screenpipe` was not present as a local command in this environment during the audit.
|
||||
|
||||
For V1, Screenpipe is deferred and out of scope. No active Screenpipe input lane was verified or adopted in the final V1 policy.
|
||||
|
||||
## Current implementation shape
|
||||
|
||||
### What OpenClaw can do safely right now
|
||||
|
||||
The current safe, directly verified OpenClaw -> AtoCore path is:
|
||||
|
||||
- project detection
|
||||
- context build
|
||||
- query and retrieval
|
||||
- project-state read
|
||||
- service inspection
|
||||
- fail-open fallback
|
||||
|
||||
That is the mature part of the integration.
|
||||
|
||||
### What OpenClaw can also do today, but should be treated as controlled operator actions
|
||||
|
||||
The current helper also exposes:
|
||||
|
||||
- project proposal preview
|
||||
- project registration
|
||||
- project update
|
||||
- project refresh
|
||||
- ingest-sources
|
||||
|
||||
These should not be treated as background or conversational automation. They are operator actions and need explicit approval policy.
|
||||
|
||||
### What exists in AtoCore but is not exposed through the OpenClaw helper
|
||||
|
||||
The shared operator client already supports:
|
||||
|
||||
- interaction capture
|
||||
- candidate extraction
|
||||
- queue review
|
||||
- promote or reject
|
||||
- trusted project-state write and invalidate
|
||||
|
||||
The current OpenClaw helper does not expose that surface.
|
||||
|
||||
This is important for V1 design: the write-capable lanes already exist in AtoCore, but they are not yet safely shaped for Discord-originated automation.
|
||||
|
||||
## Conflicts with the target V1 stance
|
||||
|
||||
The following conflicts are real and should be named explicitly.
|
||||
|
||||
### Conflict 1 - the OpenClaw helper is described as read-only, but it is not read-only
|
||||
|
||||
`SKILL.md` frames the integration as read-only additive context.
|
||||
`atocore.sh` exposes mutating operations:
|
||||
|
||||
- `register-project`
|
||||
- `update-project`
|
||||
- `refresh-project`
|
||||
- `ingest-sources`
|
||||
|
||||
That mismatch needs a policy fix in Phase 2. For Phase 1 it must be documented as a conflict.
|
||||
|
||||
### Conflict 2 - OpenClaw duplicates client logic instead of using the shared operator client
|
||||
|
||||
The architecture docs prefer a shared operator client reused across frontends.
|
||||
The OpenClaw helper currently reimplements request logic and project detection in Bash.
|
||||
|
||||
That is a direct conflict with the preferred shared-client pattern.
|
||||
|
||||
### Conflict 3 - mutating project operations are too close to the conversational surface
|
||||
|
||||
The helper makes registry and ingestion operations reachable from the OpenClaw side without a dedicated Discord-specific approval gate.
|
||||
|
||||
Even if the human explicitly asks for a refresh, the current shape does not yet distinguish between:
|
||||
|
||||
- a direct trusted operator action in a controlled session
|
||||
- a Discord-originated conversational path that should require an explicit human approval step before mutation
|
||||
|
||||
The Phase 2 V1 policy needs that distinction.
|
||||
|
||||
### Conflict 4 - current docs overstate or blur write capabilities
|
||||
|
||||
`docs/current-state.md` says OpenClaw can seed AtoCore through project-scoped memory entries and staged document ingestion.
|
||||
That was not directly verified through the current OpenClaw helper surface in `/home/papa/clawd`.
|
||||
|
||||
The helper script does not expose:
|
||||
|
||||
- `capture`
|
||||
- `extract`
|
||||
- `promote`
|
||||
- `reject`
|
||||
- `project-state-set`
|
||||
|
||||
So there is at least a documentation and runtime-surface mismatch.
|
||||
|
||||
### Conflict 5 - there was no single OpenClaw-facing evidence lane description before this doc set
|
||||
|
||||
The target architecture needs a clean distinction between:
|
||||
|
||||
- raw evidence
|
||||
- reviewable candidates
|
||||
- active memories and entities
|
||||
- trusted project_state
|
||||
|
||||
Today that distinction exists conceptually across several AtoCore docs, but before this Phase 1 doc set there was no single OpenClaw-facing operating model that told an operator exactly where Discord and Discrawl signals are allowed to land.
|
||||
|
||||
That is the main gap this doc set closes.
|
||||
|
||||
## What is already aligned with the target V1 stance
|
||||
|
||||
Several important pieces are already aligned.
|
||||
|
||||
### Aligned 1 - additive plus fail-open
|
||||
|
||||
Both AtoCore and OpenClaw docs consistently say AtoCore should be additive and fail-open from the OpenClaw side.
|
||||
That is the right baseline and was verified live.
|
||||
|
||||
### Aligned 2 - project_state is already treated as special and curated
|
||||
|
||||
AtoCore architecture docs already treat `project_state` as the highest-trust curated layer.
|
||||
This supports the rule that raw signals must not directly auto-write trusted project state.
|
||||
|
||||
### Aligned 3 - canonical-home thinking already exists
|
||||
|
||||
`docs/architecture/representation-authority.md` already establishes that each fact type needs one canonical home.
|
||||
That is exactly the right foundation for the Discord and Discrawl design.
|
||||
|
||||
### Aligned 4 - reflection and candidate lifecycle already exists in AtoCore
|
||||
|
||||
The shared operator client and AtoCore docs already have a candidate workflow:
|
||||
|
||||
- capture
|
||||
- extract
|
||||
- queue
|
||||
- promote or reject
|
||||
|
||||
That means V1 does not need to invent a new trust model. It needs to apply the existing one correctly to Discord and Discrawl signals.
|
||||
|
||||
## Recommended V1 operating interpretation
|
||||
|
||||
Until implementation work begins, the safest V1 operating interpretation is:
|
||||
|
||||
1. Discord and Discrawl are evidence sources, not truth sources.
|
||||
2. OpenClaw is the orchestrator and operator, not canonical storage.
|
||||
3. AtoCore memories may hold reviewed episodic, personal, and loose project signal.
|
||||
4. Future AtoCore entities should hold reviewed structured decisions, requirements, and constraints.
|
||||
5. `project_state` remains manual or tightly gated only.
|
||||
6. Registry mutation, refresh, ingestion, and candidate promotion or rejection require explicit human approval on Discord-originated paths.
|
||||
7. The shared operator client should become the only write-capable operator surface reused by OpenClaw and other frontends.
|
||||
8. Screenpipe remains deferred and out of V1 scope.
|
||||
|
||||
## Assumption log
|
||||
|
||||
The following points were not directly verified and must stay labeled as assumptions.
|
||||
|
||||
1. Screenpipe integration shape is unverified and deferred.
|
||||
- The `screenpipe` command was not present locally.
|
||||
- No verified Screenpipe pipeline files were found in the inspected workspaces.
|
||||
- V1 therefore excludes Screenpipe from active policy and runtime scope.
|
||||
|
||||
2. No direct Discord -> AtoCore auto-mutation path was verified in code.
|
||||
- The OpenClaw workspace clearly contains read and query context behavior and a Discrawl retrieval rule.
|
||||
- It does not clearly expose a verified Discord-triggered path that auto-calls `project-state-set`, `promote`, `reject`, or `register-project`.
|
||||
- The risk is therefore policy and proximity of commands, not a proven live mutation bug.
|
||||
|
||||
3. OpenClaw runtime use of the shared operator client was not verified because it is not implemented yet.
|
||||
- The shared client exists in the AtoCore repo.
|
||||
- The OpenClaw helper is still its own Bash implementation.
|
||||
|
||||
4. A dedicated evidence store was not verified as a first-class AtoCore schema layer.
|
||||
- Existing AtoCore surfaces clearly support interactions and candidate memories.
|
||||
- This V1 model therefore uses evidence artifacts, interactions, and archive bundles as an architectural lane, without claiming a new implemented table already exists.
|
||||
|
||||
5. Future entities remain future.
|
||||
- The entity layer is architected in AtoCore docs.
|
||||
- This audit did not verify a production entity promotion flow being used by OpenClaw.
|
||||
|
||||
## Bottom line
|
||||
|
||||
The good news is that the trust foundations already exist.
|
||||
|
||||
The main conclusion is that the current system is closest to a safe V1 when interpreted this way:
|
||||
|
||||
- keep AtoCore additive and fail-open
|
||||
- treat Discord and Discrawl as evidence only
|
||||
- route reviewed signal into memory candidates first
|
||||
- reserve `project_state` for explicit curation only
|
||||
- move OpenClaw toward the shared operator client instead of maintaining a separate write-capable helper surface
|
||||
- keep Screenpipe out of V1
|
||||
|
||||
That gives a coherent path to Phase 2 without pretending the current implementation is already there.
|
||||
@@ -1,224 +0,0 @@
|
||||
commit 80bd99aaea1bcab2ea5ea732df2f749e84d84318
|
||||
Author: Anto01 <antoine.letarte@gmail.com>
|
||||
Date: Thu Apr 23 15:59:59 2026 +0000
|
||||
|
||||
Tighten OpenClaw AtoCore governance policy
|
||||
|
||||
diff --git a/AGENTS.md b/AGENTS.md
|
||||
index 1da3385..ea4d103 100644
|
||||
--- a/AGENTS.md
|
||||
+++ b/AGENTS.md
|
||||
@@ -105,7 +105,7 @@ Reactions are lightweight social signals. Humans use them constantly — they sa
|
||||
|
||||
## Tools
|
||||
|
||||
-When a task is contextual and project-dependent, use the `atocore-context` skill to query Dalidou-hosted AtoCore for trusted project state, retrieval, context-building, registered project refresh, or project registration discovery when that will improve accuracy. Treat AtoCore as additive and fail-open; do not replace OpenClaw's own memory with it. Prefer `projects` and `refresh-project <id>` when a known project needs a clean source refresh, and use `project-template` when proposing a new project registration, and `propose-project ...` when you want a normalized preview before editing the registry manually.
|
||||
+When a task is contextual and project-dependent, use the `atocore-context` skill to query Dalidou-hosted AtoCore for trusted project-state reads, retrieval, and context-building when that will improve accuracy. Treat AtoCore as additive and fail-open; do not replace OpenClaw's own memory with it.
|
||||
|
||||
### Organic AtoCore Routing
|
||||
|
||||
@@ -116,14 +116,60 @@ Use AtoCore first when the prompt:
|
||||
- asks about architecture, constraints, status, requirements, vendors, planning, prior decisions, or current project truth
|
||||
- would benefit from cross-source context instead of only the local repo
|
||||
|
||||
-Preferred flow:
|
||||
+Preferred read path:
|
||||
1. `auto-context "<prompt>" 3000` for most project knowledge questions
|
||||
2. `project-state <project>` when the user is clearly asking for trusted current truth
|
||||
-3. `refresh-project <id>` before answering if the user explicitly asked to refresh or ingest project changes
|
||||
+3. fall back to normal OpenClaw tools and memory if AtoCore returns `no_project_match` or is unavailable
|
||||
|
||||
Do not force AtoCore for purely local coding actions like fixing a function, editing one file, or running tests, unless broader project context is likely to matter.
|
||||
|
||||
-If `auto-context` returns `no_project_match` or AtoCore is unavailable, continue normally with OpenClaw's own tools and memory.
|
||||
+### AtoCore Governance
|
||||
+
|
||||
+Default Discord posture for AtoCore is read-only and additive.
|
||||
+
|
||||
+Discord-originated or Discrawl-originated context may inform:
|
||||
+- evidence collection
|
||||
+- retrieval
|
||||
+- context building
|
||||
+- candidate review preparation
|
||||
+
|
||||
+It must not directly perform AtoCore mutating actions.
|
||||
+
|
||||
+Mutating AtoCore actions include:
|
||||
+- `register-project`
|
||||
+- `update-project`
|
||||
+- `refresh-project`
|
||||
+- `ingest-sources`
|
||||
+- `project-state-set`
|
||||
+- `project-state-invalidate`
|
||||
+- `promote`
|
||||
+- `reject`
|
||||
+- any future trusted-state or review mutation
|
||||
+
|
||||
+These actions require explicit human approval for the specific action in the current thread or session.
|
||||
+Do not infer approval from:
|
||||
+- prior Discord discussion
|
||||
+- Discrawl archive recall
|
||||
+- screener output
|
||||
+- vague intent like "we should probably refresh this"
|
||||
+
|
||||
+Hard rules:
|
||||
+- no direct Discord -> `project_state`
|
||||
+- no direct Discord -> register / update / refresh / ingest / promote / reject
|
||||
+- no hidden mutation inside screening or review-prep flows
|
||||
+- PKM notes are not the main operator instruction surface for AtoCore behavior
|
||||
+
|
||||
+### Discord Archive Retrieval (discrawl)
|
||||
+
|
||||
+When Antoine asks in natural language about prior project discussions, decisions, thread history, answers, or whether something was already discussed in Discord, use the local `discrawl` archive automatically.
|
||||
+
|
||||
+Rules:
|
||||
+- Antoine should not need to remember or type `discrawl` commands.
|
||||
+- Treat Discord history as a normal background retrieval source, like memory or project docs.
|
||||
+- Use `discrawl` silently when it will materially improve recall or confidence.
|
||||
+- Prefer this for prompts like "what did we decide", "did we discuss", "summarize the thread", "what were the open questions", or anything clearly anchored in prior Discord conversation.
|
||||
+- If both AtoCore and Discord history are relevant, use both and synthesize.
|
||||
+- If `discrawl` is stale or unavailable, say so briefly and continue with the best available context.
|
||||
|
||||
Skills provide your tools. When you need one, check its `SKILL.md`. Keep local notes (camera names, SSH details, voice preferences) in `TOOLS.md`.
|
||||
|
||||
diff --git a/skills/atocore-context/SKILL.md b/skills/atocore-context/SKILL.md
|
||||
index e42a7b7..fa23207 100644
|
||||
--- a/skills/atocore-context/SKILL.md
|
||||
+++ b/skills/atocore-context/SKILL.md
|
||||
@@ -1,12 +1,11 @@
|
||||
---
|
||||
name: atocore-context
|
||||
-description: Use Dalidou-hosted AtoCore as a read-only external context service for project state, retrieval, and context-building without touching OpenClaw's own memory.
|
||||
+description: Use Dalidou-hosted AtoCore as an additive external context service for project-state reads, retrieval, and context-building without replacing OpenClaw's own memory.
|
||||
---
|
||||
|
||||
# AtoCore Context
|
||||
|
||||
-Use this skill when you need trusted project context, retrieval help, or AtoCore
|
||||
-health/status from the canonical Dalidou instance.
|
||||
+Use this skill when you need trusted project context, retrieval help, or AtoCore health and status from the canonical Dalidou instance.
|
||||
|
||||
## Purpose
|
||||
|
||||
@@ -14,7 +13,7 @@ AtoCore is an additive external context service.
|
||||
|
||||
- It does not replace OpenClaw's own memory.
|
||||
- It should be used for contextual work, not trivial prompts.
|
||||
-- It is read-only in this first integration batch.
|
||||
+- The default posture is read-only and fail-open.
|
||||
- If AtoCore is unavailable, continue normally.
|
||||
|
||||
## Canonical Endpoint
|
||||
@@ -31,27 +30,22 @@ Override with:
|
||||
ATOCORE_BASE_URL=http://host:port
|
||||
```
|
||||
|
||||
-## Safe Usage
|
||||
+## V1 scope
|
||||
|
||||
-Use AtoCore for:
|
||||
-- project-state checks
|
||||
+Use this skill in V1 for:
|
||||
+
|
||||
+- project-state reads
|
||||
- automatic project detection for normal project questions
|
||||
-- retrieval over ingested project/ecosystem docs
|
||||
+- retrieval over ingested project and ecosystem docs
|
||||
- context-building for complex project prompts
|
||||
- verifying current AtoCore hosting and architecture state
|
||||
-- listing registered projects and refreshing a known project source set
|
||||
-- inspecting the project registration template before proposing a new project entry
|
||||
-- generating a proposal preview for a new project registration without writing it
|
||||
-- registering an approved project entry when explicitly requested
|
||||
-- updating an existing registered project when aliases or description need refinement
|
||||
+- inspecting project registrations and proposal previews when operator review is needed
|
||||
|
||||
-Do not use AtoCore for:
|
||||
-- automatic memory write-back
|
||||
-- replacing OpenClaw memory
|
||||
-- silent ingestion of broad new corpora without approval
|
||||
-- mutating the registry automatically without human approval
|
||||
+Screenpipe is out of V1 scope. Do not treat it as an active input lane or dependency for this skill.
|
||||
+
|
||||
+## Read path commands
|
||||
|
||||
-## Commands
|
||||
+These are the normal additive commands:
|
||||
|
||||
```bash
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh health
|
||||
@@ -62,15 +56,56 @@ Do not use AtoCore for:
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh detect-project "what's the interferometer error budget?"
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh auto-context "what's the interferometer error budget?" 3000
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh debug-context
|
||||
-~/clawd/skills/atocore-context/scripts/atocore.sh propose-project p07-example "p07,example-project" vault incoming/projects/p07-example "Example project" "Primary staged project docs"
|
||||
-~/clawd/skills/atocore-context/scripts/atocore.sh register-project p07-example "p07,example-project" vault incoming/projects/p07-example "Example project" "Primary staged project docs"
|
||||
-~/clawd/skills/atocore-context/scripts/atocore.sh update-project p05 "Curated staged docs for the P05 interferometer architecture, vendors, and error-budget project."
|
||||
-~/clawd/skills/atocore-context/scripts/atocore.sh refresh-project p05
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh project-state atocore
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh query "What is AtoDrive?"
|
||||
~/clawd/skills/atocore-context/scripts/atocore.sh context-build "Need current AtoCore architecture" atocore 3000
|
||||
```
|
||||
|
||||
+## Approved operator actions only
|
||||
+
|
||||
+The helper currently exposes some mutating commands, but they are not normal background behavior.
|
||||
+Treat them as approved operator actions only:
|
||||
+
|
||||
+```bash
|
||||
+~/clawd/skills/atocore-context/scripts/atocore.sh propose-project ...
|
||||
+~/clawd/skills/atocore-context/scripts/atocore.sh register-project ...
|
||||
+~/clawd/skills/atocore-context/scripts/atocore.sh update-project ...
|
||||
+~/clawd/skills/atocore-context/scripts/atocore.sh refresh-project ...
|
||||
+~/clawd/skills/atocore-context/scripts/atocore.sh ingest-sources
|
||||
+```
|
||||
+
|
||||
+Do not use these from a Discord-originated path unless the human explicitly approves the specific action in the current thread or session.
|
||||
+
|
||||
+## Explicit approval rule
|
||||
+
|
||||
+Explicit approval means all of the following:
|
||||
+
|
||||
+- the human directly instructs the specific mutating action
|
||||
+- the instruction is in the current thread or current session
|
||||
+- the approval is for that specific action
|
||||
+- the approval is not inferred from Discord evidence, Discrawl recall, screener output, or vague intent
|
||||
+
|
||||
+Examples of explicit approval:
|
||||
+
|
||||
+- "refresh p05 now"
|
||||
+- "register this project"
|
||||
+- "update the aliases"
|
||||
+
|
||||
+Non-examples:
|
||||
+
|
||||
+- "we should probably refresh this"
|
||||
+- archived discussion suggesting a refresh
|
||||
+- a screener note recommending promotion or ingestion
|
||||
+
|
||||
+## Do not use AtoCore for
|
||||
+
|
||||
+- automatic memory write-back
|
||||
+- replacing OpenClaw memory
|
||||
+- silent ingestion of broad new corpora without approval
|
||||
+- automatic registry mutation
|
||||
+- direct Discord-originated mutation of trusted or operator state
|
||||
+- direct Discord-originated promote or reject actions
|
||||
+
|
||||
## Contract
|
||||
|
||||
- prefer AtoCore only when additional context is genuinely useful
|
||||
@@ -79,10 +114,6 @@ Do not use AtoCore for:
|
||||
- cite when information came from AtoCore rather than local OpenClaw memory
|
||||
- for normal project knowledge questions, prefer `auto-context "<prompt>" 3000` before answering
|
||||
- use `detect-project "<prompt>"` when you want to inspect project inference explicitly
|
||||
-- use `debug-context` right after `auto-context` or `context-build` when you want
|
||||
- to inspect the exact last AtoCore context pack
|
||||
-- prefer `projects` plus `refresh-project <id>` over long ad hoc ingest instructions when the project is already registered
|
||||
-- use `project-template` when preparing a new project registration proposal
|
||||
-- use `propose-project ...` to draft a normalized entry and review collisions first
|
||||
-- use `register-project ...` only after the proposal has been reviewed and approved
|
||||
-- use `update-project ...` when a registered project's description or aliases need refinement before refresh
|
||||
+- use `debug-context` right after `auto-context` or `context-build` when you want to inspect the exact last AtoCore context pack
|
||||
+- use `project-template` and `propose-project ...` when preparing a reviewed registration proposal
|
||||
+- use `register-project ...`, `update-project ...`, `refresh-project ...`, and `ingest-sources` only after explicit approval
|
||||
@@ -1,354 +0,0 @@
|
||||
# OpenClaw x AtoCore Nightly Screener Runbook
|
||||
|
||||
## Purpose
|
||||
|
||||
The nightly screener is the V1 bridge between broad evidence capture and narrow trusted state.
|
||||
|
||||
Its job is to:
|
||||
|
||||
- gather raw evidence from approved V1 sources
|
||||
- reduce noise
|
||||
- produce reviewable candidate material
|
||||
- prepare operator review work
|
||||
- never silently create trusted truth
|
||||
|
||||
## Scope
|
||||
|
||||
The nightly screener is a screening and preparation job.
|
||||
It is not a trusted-state writer.
|
||||
It is not a registry operator.
|
||||
It is not a hidden reviewer.
|
||||
|
||||
V1 active inputs are:
|
||||
|
||||
- Discord and Discrawl evidence
|
||||
- OpenClaw interaction evidence
|
||||
- PKM, repos, and KB references
|
||||
- read-only AtoCore context for comparison and deduplication
|
||||
|
||||
## Explicit approval rule
|
||||
|
||||
If the screener output points at a mutating operator action, that action still requires:
|
||||
|
||||
- direct human instruction
|
||||
- in the current thread or current session
|
||||
- for that specific action
|
||||
- with no inference from evidence or screener output alone
|
||||
|
||||
The screener may recommend review. It may not manufacture approval.
|
||||
|
||||
## Inputs
|
||||
|
||||
The screener may consume the following inputs when available.
|
||||
|
||||
### 1. Discord and Discrawl evidence
|
||||
|
||||
Examples:
|
||||
|
||||
- recent archived Discord messages
|
||||
- thread excerpts relevant to known projects
|
||||
- conversation clusters around decisions, requirements, constraints, or repeated questions
|
||||
|
||||
### 2. OpenClaw interaction evidence
|
||||
|
||||
Examples:
|
||||
|
||||
- captured interactions
|
||||
- recent operator conversations relevant to projects
|
||||
- already-logged evidence bundles
|
||||
|
||||
### 3. Read-only AtoCore context inputs
|
||||
|
||||
Examples:
|
||||
|
||||
- project registry lookup for project matching
|
||||
- project_state read for comparison only
|
||||
- memory or entity lookups for deduplication only
|
||||
|
||||
These reads may help the screener rank or classify candidates, but they must not be used as a write side effect.
|
||||
|
||||
### 4. Optional canonical-source references
|
||||
|
||||
Examples:
|
||||
|
||||
- PKM notes
|
||||
- repo docs
|
||||
- KB-export summaries
|
||||
|
||||
These may be consulted to decide whether a signal appears to duplicate or contradict already-canonical truth.
|
||||
|
||||
## Outputs
|
||||
|
||||
The screener should produce output in four buckets.
|
||||
|
||||
### 1. Nightly screener report
|
||||
|
||||
A compact report describing:
|
||||
|
||||
- inputs seen
|
||||
- items skipped
|
||||
- candidate counts
|
||||
- project match confidence distribution
|
||||
- failures or unavailable sources
|
||||
- items requiring human review
|
||||
|
||||
### 2. Evidence bundle or manifest
|
||||
|
||||
A structured bundle of the source snippets that justified each candidate or unresolved item.
|
||||
This is the reviewer's provenance package.
|
||||
|
||||
### 3. Candidate manifests
|
||||
|
||||
Separate candidate manifests for:
|
||||
|
||||
- memory candidates
|
||||
- entity candidates later
|
||||
- unresolved "needs canonical-source update first" items
|
||||
|
||||
### 4. Operator action queue
|
||||
|
||||
A short list of items needing explicit human action, such as:
|
||||
|
||||
- review these candidates
|
||||
- decide whether to refresh project X
|
||||
- decide whether to curate project_state
|
||||
- decide whether a Discord-originated claim should first be reflected in PKM, repo, or KB
|
||||
|
||||
## Required non-output
|
||||
|
||||
The screener must not directly produce any of the following:
|
||||
|
||||
- active memories without review
|
||||
- active entities without review
|
||||
- project_state writes
|
||||
- registry mutation
|
||||
- refresh operations
|
||||
- ingestion operations
|
||||
- promote or reject decisions
|
||||
|
||||
## Nightly procedure
|
||||
|
||||
### Step 1 - load last-run checkpoint
|
||||
|
||||
Read the last successful screener checkpoint so the run knows:
|
||||
|
||||
- what time range to inspect
|
||||
- what evidence was already processed
|
||||
- which items were already dropped or bundled
|
||||
|
||||
If no checkpoint exists, use a conservative bounded time window and mark the run as bootstrap mode.
|
||||
|
||||
### Step 2 - gather evidence
|
||||
|
||||
Collect available evidence from each configured source.
|
||||
|
||||
Per-source rule:
|
||||
|
||||
- source unavailable -> note it, continue
|
||||
- source empty -> note it, continue
|
||||
- source noisy -> keep raw capture bounded and deduplicated
|
||||
|
||||
### Step 3 - normalize and deduplicate
|
||||
|
||||
For each collected item:
|
||||
|
||||
- normalize timestamps, source ids, and project hints
|
||||
- remove exact duplicates
|
||||
- group repeated or near-identical evidence when practical
|
||||
- keep provenance pointers intact
|
||||
|
||||
The goal is to avoid flooding review with repeated copies of the same conversation.
|
||||
|
||||
### Step 4 - attempt project association
|
||||
|
||||
For each evidence item, try to associate it with:
|
||||
|
||||
- a registered project id, or
|
||||
- `unassigned` if confidence is low
|
||||
|
||||
Rules:
|
||||
|
||||
- high confidence match -> attach project id
|
||||
- low confidence match -> mark as uncertain
|
||||
- no good match -> leave unassigned
|
||||
|
||||
Do not force a project assignment just to make the output tidier.
|
||||
|
||||
### Step 5 - classify signal type
|
||||
|
||||
Classify each normalized item into one of these buckets:
|
||||
|
||||
- noise / ignore
|
||||
- evidence only
|
||||
- memory candidate
|
||||
- entity candidate
|
||||
- needs canonical-source update first
|
||||
- needs explicit operator decision
|
||||
|
||||
If the classification is uncertain, choose the lower-trust bucket.
|
||||
|
||||
### Step 6 - compare against higher-trust layers
|
||||
|
||||
For non-noise items, compare against the current higher-trust landscape.
|
||||
|
||||
Check for:
|
||||
|
||||
- already-active equivalent memory
|
||||
- already-active equivalent entity later
|
||||
- existing project_state answer
|
||||
- obvious duplication of canonical source truth
|
||||
- obvious contradiction with canonical source truth
|
||||
|
||||
This comparison is read-only.
|
||||
It is used only to rank and annotate output.
|
||||
|
||||
### Step 7 - build candidate bundles
|
||||
|
||||
For each candidate:
|
||||
|
||||
- include the candidate text or shape
|
||||
- include provenance snippets
|
||||
- include source type
|
||||
- include project association confidence
|
||||
- include reason for candidate classification
|
||||
- include conflict or duplicate notes if found
|
||||
|
||||
### Step 8 - build unresolved operator queue
|
||||
|
||||
Some items should not become candidates yet.
|
||||
Examples:
|
||||
|
||||
- "This looks like current truth but should first be updated in PKM, repo, or KB."
|
||||
- "This Discord-originated request asks for refresh or ingest."
|
||||
- "This might be a decision, but confidence is too low."
|
||||
|
||||
These belong in a small operator queue, not in trusted state.
|
||||
|
||||
### Step 9 - persist report artifacts only
|
||||
|
||||
Persist only:
|
||||
|
||||
- screener report
|
||||
- evidence manifests
|
||||
- candidate manifests
|
||||
- checkpoint metadata
|
||||
|
||||
If candidate persistence into AtoCore is enabled later, it still remains a candidate-only path and must not skip review.
|
||||
|
||||
### Step 10 - exit fail-open
|
||||
|
||||
If the screener could not reach AtoCore or some source system:
|
||||
|
||||
- write the failure or skip into the report
|
||||
- keep the checkpoint conservative
|
||||
- do not fake success
|
||||
- do not silently mutate anything elsewhere
|
||||
|
||||
## Failure modes
|
||||
|
||||
### Failure mode 1 - AtoCore unavailable
|
||||
|
||||
Behavior:
|
||||
|
||||
- continue in fail-open mode if possible
|
||||
- write a report that the run was evidence-only or degraded
|
||||
- do not attempt write-side recovery actions
|
||||
|
||||
### Failure mode 2 - Discrawl unavailable or stale
|
||||
|
||||
Behavior:
|
||||
|
||||
- note Discord archive input unavailable or stale
|
||||
- continue with other sources
|
||||
- do not invent Discord evidence summaries
|
||||
|
||||
### Failure mode 3 - candidate explosion
|
||||
|
||||
Behavior:
|
||||
|
||||
- rank candidates
|
||||
- keep only a bounded top set for review
|
||||
- put the remainder into a dropped or deferred manifest
|
||||
- do not overwhelm the reviewer queue
|
||||
|
||||
### Failure mode 4 - low-confidence project mapping
|
||||
|
||||
Behavior:
|
||||
|
||||
- leave items unassigned or uncertain
|
||||
- do not force them into a project-specific truth lane
|
||||
|
||||
### Failure mode 5 - contradiction with trusted truth
|
||||
|
||||
Behavior:
|
||||
|
||||
- flag the contradiction in the report
|
||||
- keep the evidence or candidate for review if useful
|
||||
- do not overwrite project_state
|
||||
|
||||
### Failure mode 6 - direct operator-action request found in evidence
|
||||
|
||||
Examples:
|
||||
|
||||
- "register this project"
|
||||
- "refresh this source"
|
||||
- "promote this memory"
|
||||
|
||||
Behavior:
|
||||
|
||||
- place the item into the operator action queue
|
||||
- require explicit human approval
|
||||
- do not perform the mutation as part of the screener
|
||||
|
||||
## Review handoff format
|
||||
|
||||
Each screener run should hand off a compact review package containing:
|
||||
|
||||
1. a run summary
|
||||
2. candidate counts by type and project
|
||||
3. top candidates with provenance
|
||||
4. unresolved items needing explicit operator choice
|
||||
5. unavailable-source notes
|
||||
6. checkpoint status
|
||||
|
||||
The handoff should be short enough for a human to review without reading the entire raw archive.
|
||||
|
||||
## Safety rules
|
||||
|
||||
The screener must obey these rules every night.
|
||||
|
||||
1. No direct project_state writes.
|
||||
2. No direct registry mutation.
|
||||
3. No direct refresh or ingest.
|
||||
4. No direct promote or reject.
|
||||
5. No treating Discord or Discrawl as trusted truth.
|
||||
6. No hiding source uncertainty.
|
||||
7. No inventing missing integrations.
|
||||
8. No bringing deferred sources into V1 through policy drift or hidden dependency.
|
||||
|
||||
## Minimum useful run
|
||||
|
||||
A useful screener run can still succeed even if it only does this:
|
||||
|
||||
- gathers available Discord and OpenClaw evidence
|
||||
- filters obvious noise
|
||||
- produces a small candidate manifest
|
||||
- notes unavailable archive inputs if any
|
||||
- leaves trusted state untouched
|
||||
|
||||
That is still a correct V1 run.
|
||||
|
||||
## Deferred from V1
|
||||
|
||||
Screenpipe is deferred from V1. It is not an active input, not a required dependency, and not part of the runtime behavior of this V1 screener.
|
||||
|
||||
## Bottom line
|
||||
|
||||
The nightly screener is not the brain of the system.
|
||||
It is the filter.
|
||||
|
||||
Its purpose is to make human review easier while preserving the trust hierarchy:
|
||||
|
||||
- broad capture in
|
||||
- narrow reviewed truth out
|
||||
- no hidden mutations in the middle
|
||||
@@ -1,360 +0,0 @@
|
||||
# OpenClaw x AtoCore V1 Promotion Pipeline
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines the V1 promotion pipeline for signals coming from Discord, Discrawl, OpenClaw, PKM, and repos.
|
||||
|
||||
The rule is simple:
|
||||
|
||||
- raw capture is evidence
|
||||
- screening turns evidence into candidate material
|
||||
- review promotes candidates into canonical homes
|
||||
- trusted state is curated explicitly, not inferred automatically
|
||||
|
||||
## V1 scope
|
||||
|
||||
V1 active inputs are:
|
||||
|
||||
- Discord live conversation
|
||||
- Discrawl archive retrieval
|
||||
- OpenClaw interaction logs and evidence bundles
|
||||
- PKM notes
|
||||
- repos, KB exports, and repo docs
|
||||
|
||||
Read-only AtoCore context may be consulted for comparison and deduplication.
|
||||
|
||||
## Explicit approval rule
|
||||
|
||||
When this pipeline refers to approval or review for a mutating action, it means:
|
||||
|
||||
- the human directly instructs the specific action
|
||||
- the instruction is in the current thread or current session
|
||||
- the approval is for that specific action
|
||||
- the approval is not inferred from evidence, archives, or screener output
|
||||
|
||||
## Pipeline summary
|
||||
|
||||
```text
|
||||
raw capture
|
||||
-> evidence bundle
|
||||
-> nightly screening
|
||||
-> candidate queue
|
||||
-> human review
|
||||
-> canonical home
|
||||
-> optional trusted-state curation
|
||||
```
|
||||
|
||||
## Stage 0 - raw capture
|
||||
|
||||
### Inputs
|
||||
|
||||
Raw capture may come from:
|
||||
|
||||
- Discord live conversation
|
||||
- Discrawl archive retrieval
|
||||
- OpenClaw interaction logs
|
||||
- PKM notes
|
||||
- repos / KB exports / repo docs
|
||||
|
||||
### Rule at this stage
|
||||
|
||||
Nothing captured here is trusted truth yet.
|
||||
Everything is either:
|
||||
|
||||
- raw evidence, or
|
||||
- a pointer to an already-canonical source
|
||||
|
||||
## Stage 1 - evidence bundle
|
||||
|
||||
The first durable V1 destination for raw signals is the evidence lane.
|
||||
|
||||
Examples of evidence bundle forms:
|
||||
|
||||
- AtoCore interaction records
|
||||
- Discrawl retrieval result sets
|
||||
- nightly screener input bundles
|
||||
- local archived artifacts or manifests
|
||||
- optional source snapshots used only for review preparation
|
||||
|
||||
### What evidence is for
|
||||
|
||||
Evidence exists so the operator can later answer:
|
||||
|
||||
- what did we actually see?
|
||||
- where did this claim come from?
|
||||
- what context supported the candidate?
|
||||
- what should the reviewer inspect before promoting anything?
|
||||
|
||||
### What evidence is not for
|
||||
|
||||
Evidence is not:
|
||||
|
||||
- active memory
|
||||
- active entity
|
||||
- trusted project_state
|
||||
- registry truth
|
||||
|
||||
## Stage 2 - screening
|
||||
|
||||
The nightly screener or an explicit review flow reads evidence and classifies it.
|
||||
|
||||
### Screening outputs
|
||||
|
||||
Each observed signal should be classified into one of these lanes:
|
||||
|
||||
1. Ignore / noise
|
||||
- chatter
|
||||
- duplicate archive material
|
||||
- ambiguous fragments
|
||||
- low-signal scraps
|
||||
|
||||
2. Keep as evidence only
|
||||
- useful context, but too ambiguous or too raw to promote
|
||||
|
||||
3. Memory candidate
|
||||
- stable enough to review as episodic, personal, or loose project signal
|
||||
|
||||
4. Entity candidate
|
||||
- structured enough to review as a future decision, requirement, constraint, or validation fact
|
||||
|
||||
5. Needs canonical-source update first
|
||||
- appears to assert current trusted truth but should first be reflected in the real canonical home, such as PKM, repo, or KB tool
|
||||
|
||||
### Key screening rule
|
||||
|
||||
If the screener cannot confidently tell whether a signal is:
|
||||
|
||||
- raw evidence,
|
||||
- a loose durable memory,
|
||||
- or a structured project truth,
|
||||
|
||||
then it must pick the lower-trust lane.
|
||||
|
||||
In V1, uncertainty resolves downward.
|
||||
|
||||
## Stage 3 - candidate queue
|
||||
|
||||
Only screened outputs may enter the candidate queue.
|
||||
|
||||
### Memory-candidate lane
|
||||
|
||||
Use this lane for reviewed-signal candidates such as:
|
||||
|
||||
- preferences
|
||||
- episodic facts
|
||||
- identity facts
|
||||
- loose stable project signal that is useful to remember but not yet a formal structured entity
|
||||
|
||||
Examples:
|
||||
|
||||
- "Antoine prefers operator summaries without extra ceremony."
|
||||
- "The team discussed moving OpenClaw toward a shared operator client."
|
||||
- "Discord history is useful as evidence but not as direct truth."
|
||||
|
||||
### Entity-candidate lane
|
||||
|
||||
Use this lane for future structured facts such as:
|
||||
|
||||
- decisions
|
||||
- requirements
|
||||
- constraints
|
||||
- validation claims
|
||||
|
||||
Examples:
|
||||
|
||||
- "Decision: use the shared operator client instead of duplicated frontend logic."
|
||||
- "Constraint: Discord-originated paths must not directly mutate project_state."
|
||||
|
||||
### What cannot enter directly from raw capture
|
||||
|
||||
The following must not be created directly from raw Discord or Discrawl evidence without a screening step:
|
||||
|
||||
- active memories
|
||||
- active entities
|
||||
- project_state entries
|
||||
- registry mutations
|
||||
- promote or reject decisions
|
||||
|
||||
## Stage 4 - human review
|
||||
|
||||
This is the load-bearing stage.
|
||||
|
||||
A human reviewer, mediated by OpenClaw and eventually using the shared operator client, decides whether the candidate:
|
||||
|
||||
- should be promoted
|
||||
- should be rejected
|
||||
- should stay pending
|
||||
- should first be rewritten into the actual canonical source
|
||||
- should become project_state only after stronger curation
|
||||
|
||||
### Review questions
|
||||
|
||||
For every candidate, the reviewer should ask:
|
||||
|
||||
1. Is this actually stable enough to preserve?
|
||||
2. Is this fact ambiguous, historical, or current?
|
||||
3. What is the one canonical home for this fact type?
|
||||
4. Is memory the right home, or should this be an entity later?
|
||||
5. Is project_state justified, or is this still only evidence or candidate material?
|
||||
6. Does the source prove current truth, or only past conversation?
|
||||
|
||||
## Stage 5 - canonical promotion
|
||||
|
||||
After review, the signal can move into exactly one canonical home.
|
||||
|
||||
## Promotion rules by fact shape
|
||||
|
||||
### A. Personal, episodic, or loose project signal
|
||||
|
||||
Promotion destination:
|
||||
|
||||
- AtoCore memory
|
||||
|
||||
Use when the fact is durable and useful, but not a formal structured engineering record.
|
||||
|
||||
### B. Structured engineering fact
|
||||
|
||||
Promotion destination:
|
||||
|
||||
- future AtoCore entity
|
||||
|
||||
Use when the fact is really a:
|
||||
|
||||
- decision
|
||||
- requirement
|
||||
- constraint
|
||||
- validation claim
|
||||
|
||||
### C. Current trusted project answer
|
||||
|
||||
Promotion destination:
|
||||
|
||||
- AtoCore project_state
|
||||
|
||||
But only after explicit curation.
|
||||
|
||||
A candidate does not become project_state just because it looks important.
|
||||
The reviewer must decide that it now represents the trusted current answer.
|
||||
|
||||
### D. Human or tool source truth
|
||||
|
||||
Promotion destination:
|
||||
|
||||
- PKM / repo / KB tool of origin
|
||||
|
||||
If a Discord-originated signal claims current truth but the canonical home is not AtoCore memory or entity, the right move may be:
|
||||
|
||||
1. update the canonical source first
|
||||
2. then optionally refresh or ingest, with explicit approval if the action is mutating
|
||||
3. then optionally curate a project_state answer
|
||||
|
||||
This prevents Discord from becoming the hidden source of truth.
|
||||
|
||||
## Stage 6 - optional trusted-state curation
|
||||
|
||||
`project_state` is not the general destination for important facts.
|
||||
It is the curated destination for current trusted project answers.
|
||||
|
||||
Examples that may justify explicit project_state curation:
|
||||
|
||||
- current selected architecture
|
||||
- current next milestone
|
||||
- current status summary
|
||||
- current trusted decision outcome
|
||||
|
||||
Examples that usually do not justify immediate project_state curation:
|
||||
|
||||
- a raw Discord debate
|
||||
- a speculative suggestion
|
||||
- a historical conversation retrieved through Discrawl
|
||||
|
||||
## Discord-originated pipeline examples
|
||||
|
||||
### Example 1 - raw discussion about operator-client refactor
|
||||
|
||||
1. Discord message enters the evidence lane.
|
||||
2. Nightly screener marks it as either evidence-only or decision candidate.
|
||||
3. Human review checks whether it is an actual decision or just discussion.
|
||||
4. If stable and approved, it becomes a memory or future entity.
|
||||
5. It reaches project_state only if explicitly curated as the trusted current answer.
|
||||
|
||||
### Example 2 - Discord thread says "refresh this project now"
|
||||
|
||||
1. Discord message is evidence of operator intent.
|
||||
2. It does not auto-trigger refresh.
|
||||
3. OpenClaw asks for or recognizes explicit human approval.
|
||||
4. Approved operator action invokes the shared operator client.
|
||||
5. Refresh result may later influence candidates or trusted state, but the raw Discord message never performed the mutation by itself.
|
||||
|
||||
### Example 3 - archived thread says a requirement might be current
|
||||
|
||||
1. Discrawl retrieval enters the evidence lane.
|
||||
2. Screener marks it as evidence-only or a requirement candidate.
|
||||
3. Human review checks the canonical source alignment.
|
||||
4. If accepted later, it becomes an entity candidate or active entity.
|
||||
5. project_state remains a separate explicit curation step.
|
||||
|
||||
## Promotion invariants
|
||||
|
||||
The pipeline must preserve these invariants.
|
||||
|
||||
### Invariant 1 - raw evidence is not trusted truth
|
||||
|
||||
No raw Discord or Discrawl signal can directly become trusted project_state.
|
||||
|
||||
### Invariant 2 - unreviewed signals can at most become candidates
|
||||
|
||||
Automatic processing stops at evidence or candidate creation.
|
||||
|
||||
### Invariant 3 - each fact has one canonical home
|
||||
|
||||
A fact may be supported by many evidence items, but after review it belongs in one canonical place.
|
||||
|
||||
### Invariant 4 - operator mutations require explicit approval
|
||||
|
||||
Registry mutation, refresh, ingest, promote, reject, and project_state writes are operator actions.
|
||||
|
||||
### Invariant 5 - OpenClaw orchestrates; it does not become storage
|
||||
|
||||
OpenClaw should coordinate the pipeline, not silently become the canonical data layer.
|
||||
|
||||
## Decision table
|
||||
|
||||
| Observed signal type | Default pipeline outcome | Canonical destination if accepted |
|
||||
|---|---|---|
|
||||
| Ambiguous or raw conversation | Evidence only | none |
|
||||
| Historical archive context | Evidence only or candidate | memory or entity only after review |
|
||||
| Personal preference | Memory candidate | AtoCore memory |
|
||||
| Episodic fact | Memory candidate | AtoCore memory |
|
||||
| Loose stable project signal | Memory candidate | AtoCore memory |
|
||||
| Structured decision / requirement / constraint | Entity candidate | future AtoCore entity |
|
||||
| Claimed current trusted answer | Needs explicit curation | project_state, but only after review |
|
||||
| Tool-origin engineering fact | Canonical source update first | repo / KB / PKM tool of origin |
|
||||
|
||||
## What the pipeline deliberately prevents
|
||||
|
||||
This V1 pipeline deliberately prevents these bad paths:
|
||||
|
||||
- Discord -> project_state directly
|
||||
- Discrawl archive -> project_state directly
|
||||
- Discord -> registry mutation directly
|
||||
- Discord -> refresh or ingest directly without explicit approval
|
||||
- raw chat -> promote or reject directly
|
||||
- OpenClaw turning evidence into truth without a review gate
|
||||
|
||||
## Deferred from V1
|
||||
|
||||
Screenpipe is deferred from V1. It is not an active input lane in this pipeline and it is not a runtime dependency of this pipeline. If it is revisited later, it should be handled in a separate future design and not treated as an implicit part of this pipeline.
|
||||
|
||||
## Bottom line
|
||||
|
||||
The promotion pipeline is intentionally conservative.
|
||||
|
||||
Its job is not to maximize writes.
|
||||
Its job is to preserve trust while still letting Discord, Discrawl, OpenClaw, PKM, and repos contribute useful signal.
|
||||
|
||||
That means the safe default path is:
|
||||
|
||||
- capture broadly
|
||||
- trust narrowly
|
||||
- promote deliberately
|
||||
@@ -1,96 +0,0 @@
|
||||
# OpenClaw x AtoCore Shared-Client Consolidation Preview
|
||||
|
||||
## Status
|
||||
|
||||
Proposal only. Not applied.
|
||||
|
||||
## Why this exists
|
||||
|
||||
The current OpenClaw helper script duplicates AtoCore-calling logic that already exists in the shared operator client:
|
||||
|
||||
- request handling
|
||||
- fail-open behavior
|
||||
- project detection
|
||||
- project lifecycle command surface
|
||||
|
||||
The preferred direction is to consolidate OpenClaw toward the shared operator client pattern documented in `docs/architecture/llm-client-integration.md`.
|
||||
|
||||
## Goal
|
||||
|
||||
Keep the OpenClaw skill and operator policy in OpenClaw, but stop maintaining a separate Bash implementation of the AtoCore client surface when the shared client already exists in `/home/papa/ATOCore/scripts/atocore_client.py`.
|
||||
|
||||
## Non-goals for this preview
|
||||
|
||||
- no implementation in this phase
|
||||
- no runtime change in this phase
|
||||
- no new helper command in this phase
|
||||
- no change to approval policy in this preview
|
||||
|
||||
## Preview diff
|
||||
|
||||
This is a conceptual diff preview only.
|
||||
It is not applied.
|
||||
|
||||
```diff
|
||||
--- a/skills/atocore-context/scripts/atocore.sh
|
||||
+++ b/skills/atocore-context/scripts/atocore.sh
|
||||
@@
|
||||
-#!/usr/bin/env bash
|
||||
-set -euo pipefail
|
||||
-
|
||||
-BASE_URL="${ATOCORE_BASE_URL:-http://dalidou:8100}"
|
||||
-TIMEOUT="${ATOCORE_TIMEOUT_SECONDS:-30}"
|
||||
-REFRESH_TIMEOUT="${ATOCORE_REFRESH_TIMEOUT_SECONDS:-1800}"
|
||||
-FAIL_OPEN="${ATOCORE_FAIL_OPEN:-true}"
|
||||
-
|
||||
-request() {
|
||||
- # local curl-based request logic
|
||||
-}
|
||||
-
|
||||
-detect_project() {
|
||||
- # local project detection logic
|
||||
-}
|
||||
-
|
||||
-case "$cmd" in
|
||||
- health) request GET /health ;;
|
||||
- projects) request GET /projects ;;
|
||||
- auto-context) ... ;;
|
||||
- register-project) ... ;;
|
||||
- refresh-project) ... ;;
|
||||
- ingest-sources) ... ;;
|
||||
-esac
|
||||
+#!/usr/bin/env bash
|
||||
+set -euo pipefail
|
||||
+
|
||||
+CLIENT="${ATOCORE_SHARED_CLIENT:-/home/papa/ATOCore/scripts/atocore_client.py}"
|
||||
+
|
||||
+if [[ ! -f "$CLIENT" ]]; then
|
||||
+ echo "Shared AtoCore client not found: $CLIENT" >&2
|
||||
+ exit 1
|
||||
+fi
|
||||
+
|
||||
+exec python3 "$CLIENT" "$@"
|
||||
```
|
||||
|
||||
## Recommended implementation shape later
|
||||
|
||||
If and when this is implemented, the safer shape is:
|
||||
|
||||
1. keep policy and approval guidance in OpenClaw instructions and skill text
|
||||
2. delegate actual AtoCore client behavior to the shared operator client
|
||||
3. avoid adding any new helper command unless explicitly approved
|
||||
4. keep read-path and approved-operator-path distinctions in the OpenClaw guidance layer
|
||||
|
||||
## Risk notes
|
||||
|
||||
Potential follow-up concerns to handle before applying:
|
||||
|
||||
- path dependency on `/home/papa/ATOCore/scripts/atocore_client.py`
|
||||
- what should happen if the AtoCore repo is unavailable from the OpenClaw machine
|
||||
- whether a thin compatibility wrapper is needed for help text or argument normalization
|
||||
- ensuring OpenClaw policy still blocks unapproved Discord-originated mutations even if the shared client exposes them
|
||||
|
||||
## Bottom line
|
||||
|
||||
The duplication is real and consolidation is still the right direction.
|
||||
But in this phase it remains a proposal only.
|
||||
@@ -1,362 +0,0 @@
|
||||
# OpenClaw x AtoCore V1 Architecture
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines the safe V1 operating model for how Discord, Discrawl, OpenClaw, PKM, repos, and AtoCore work together.
|
||||
|
||||
The goal is to let these systems contribute useful signal into AtoCore without turning AtoCore into a raw dump and without blurring trust boundaries.
|
||||
|
||||
## V1 scope
|
||||
|
||||
V1 active inputs are:
|
||||
|
||||
- Discord and Discrawl evidence
|
||||
- OpenClaw interaction evidence
|
||||
- PKM, repos, and KB sources
|
||||
- read-only AtoCore context for comparison and deduplication
|
||||
|
||||
## Core stance
|
||||
|
||||
The V1 stance is simple:
|
||||
|
||||
- Discord and Discrawl are evidence streams.
|
||||
- OpenClaw is the operator and orchestrator.
|
||||
- PKM, repos, and KB tools remain the canonical human and tool truth.
|
||||
- AtoCore memories hold reviewed episodic, personal, and loose project signal.
|
||||
- AtoCore project_state holds the current trusted project answer, manually or tightly gated only.
|
||||
- Future AtoCore entities hold reviewed structured decisions, requirements, constraints, and related facts.
|
||||
|
||||
## Architectural principles
|
||||
|
||||
1. AtoCore remains additive and fail-open from the OpenClaw side.
|
||||
2. Every fact type has exactly one canonical home.
|
||||
3. Raw evidence is not trusted truth.
|
||||
4. Unreviewed signals become evidence or candidates, not active truth.
|
||||
5. Discord-originated paths never directly mutate project_state, registry state, refresh state, ingestion state, or review decisions without explicit human approval.
|
||||
6. OpenClaw is not canonical storage. It retrieves, compares, summarizes, requests approval, and performs approved operator actions.
|
||||
7. The shared operator client is the canonical mutating operator surface. Frontends should reuse it instead of reimplementing AtoCore-calling logic.
|
||||
|
||||
## Explicit approval rule
|
||||
|
||||
In this V1 policy, explicit approval means all of the following:
|
||||
|
||||
- the human directly instructs the specific mutating action
|
||||
- the instruction appears in the current thread or current session
|
||||
- the approval is for that specific action, not vague intent
|
||||
- the approval is not inferred from Discord evidence, Discrawl recall, screener output, or general discussion
|
||||
|
||||
Examples of explicit approval:
|
||||
|
||||
- "refresh p05 now"
|
||||
- "register this project"
|
||||
- "promote that candidate"
|
||||
- "write this to project_state"
|
||||
|
||||
Examples that are not explicit approval:
|
||||
|
||||
- "we should probably refresh this sometime"
|
||||
- "I think this is the current answer"
|
||||
- archived discussion saying a mutation might be useful
|
||||
- a screener report recommending a mutation
|
||||
|
||||
## System roles
|
||||
|
||||
### Discord
|
||||
|
||||
Discord is a live conversational source.
|
||||
It contains fresh context, discussion, uncertainty, and project language grounded in real work.
|
||||
It is not authoritative by itself.
|
||||
|
||||
Discord-originated material should be treated as:
|
||||
|
||||
- raw evidence
|
||||
- candidate material after screening
|
||||
- possible justification for a later human-reviewed promotion into a canonical home
|
||||
|
||||
Discord should never be treated as direct trusted project truth just because someone said it in chat.
|
||||
|
||||
### Discrawl
|
||||
|
||||
Discrawl is a retrieval and archive layer over Discord history.
|
||||
It turns prior conversation into searchable evidence.
|
||||
That is useful for recall, context building, and finding prior decisions or open questions.
|
||||
|
||||
Discrawl is still evidence, not authority.
|
||||
A retrieved Discord thread may show what people thought or said. It does not by itself become trusted project_state.
|
||||
|
||||
### OpenClaw
|
||||
|
||||
OpenClaw is the orchestrator and operator.
|
||||
It is where the human interacts, where approvals happen, and where cross-source reasoning happens.
|
||||
|
||||
OpenClaw's job is to:
|
||||
|
||||
- retrieve
|
||||
- compare
|
||||
- summarize
|
||||
- ask for approval when mutation is requested
|
||||
- call the shared operator client for approved writes
|
||||
- fail open when AtoCore is unavailable
|
||||
|
||||
OpenClaw is not the canonical place where project facts live long-term.
|
||||
|
||||
### PKM
|
||||
|
||||
PKM is a canonical human-authored prose source.
|
||||
It is where notes, thinking, and ongoing project writing live.
|
||||
|
||||
PKM is the canonical home for:
|
||||
|
||||
- project prose notes
|
||||
- working notes
|
||||
- long-form summaries
|
||||
- journal-style project history
|
||||
|
||||
PKM is not the place where OpenClaw should be taught how to operate AtoCore. Operator instructions belong in repo docs and OpenClaw instructions and skills.
|
||||
|
||||
### Repos and KB tools
|
||||
|
||||
Repos and KB tools are canonical human and tool truth for code and structured engineering artifacts.
|
||||
|
||||
They are the canonical home for:
|
||||
|
||||
- source code
|
||||
- repo design docs
|
||||
- structured tool outputs
|
||||
- KB-CAD and KB-FEM facts where those systems are the tool of origin
|
||||
|
||||
### AtoCore memories
|
||||
|
||||
AtoCore memories are for reviewed, durable machine-usable signal that is still loose enough to belong in memory rather than in a stricter structured layer.
|
||||
|
||||
Examples:
|
||||
|
||||
- episodic facts
|
||||
- preferences
|
||||
- identity facts
|
||||
- reviewed loose project facts
|
||||
|
||||
AtoCore memories are not a place to dump raw Discord capture.
|
||||
|
||||
### AtoCore project_state
|
||||
|
||||
AtoCore project_state is the trusted current answer layer.
|
||||
It is the place for questions like:
|
||||
|
||||
- what is the current selected architecture?
|
||||
- what is the current next focus?
|
||||
- what is the trusted status answer right now?
|
||||
|
||||
Because this layer answers current-truth questions, it must remain manually curated or tightly gated.
|
||||
|
||||
### Future AtoCore entities
|
||||
|
||||
Future entities are the canonical home for structured engineering facts that deserve stronger representation than freeform memory.
|
||||
|
||||
Examples:
|
||||
|
||||
- decisions
|
||||
- requirements
|
||||
- constraints
|
||||
- validation claims
|
||||
- structured relationships later
|
||||
|
||||
These should be promoted from evidence or candidates only after review.
|
||||
|
||||
## Logical flow
|
||||
|
||||
```text
|
||||
Discord live chat --.
|
||||
Discrawl archive ----+--> evidence bundle / interactions / screener input
|
||||
OpenClaw evidence ---'
|
||||
|
|
||||
v
|
||||
nightly screener
|
||||
|
|
||||
.--------+--------.
|
||||
v v
|
||||
memory candidates entity candidates (later)
|
||||
| |
|
||||
'--------+--------'
|
||||
v
|
||||
human review in OpenClaw
|
||||
|
|
||||
.-----------------+-----------------.
|
||||
v v v
|
||||
active memory active entity explicit curation
|
||||
|
|
||||
v
|
||||
project_state
|
||||
```
|
||||
|
||||
The load-bearing rule is that review happens before trust.
|
||||
|
||||
## Canonical-home table
|
||||
|
||||
Every named fact type below has exactly one canonical home.
|
||||
|
||||
| Fact type | Canonical home | Why |
|
||||
|---|---|---|
|
||||
| Raw Discord message | Discord / Discrawl archive | It is conversational evidence, not normalized truth |
|
||||
| Archived Discord thread history | Discrawl archive | It is the retrieval form of Discord evidence |
|
||||
| OpenClaw operator instructions | OpenClaw repo docs / skills / instructions | Operating behavior should live in code-adjacent instructions, not PKM |
|
||||
| Project prose notes | PKM | Human-authored project prose belongs in PKM |
|
||||
| Source code | Repo | Code truth lives in version control |
|
||||
| Repo design or architecture doc | Repo | The documentation belongs with the code or system it describes |
|
||||
| Structured KB-CAD / KB-FEM fact | KB tool of origin | Tool-managed structured engineering facts belong in their tool of origin |
|
||||
| Personal identity fact | AtoCore memory (`identity`) | AtoCore memory is the durable machine-usable home |
|
||||
| Preference fact | AtoCore memory (`preference`) | Same reason |
|
||||
| Episodic fact | AtoCore memory (`episodic`) | It is durable recall, not project_state |
|
||||
| Loose reviewed project signal | AtoCore memory (`project`) | Good fit for reviewed but not fully structured project signal |
|
||||
| Engineering decision | Future AtoCore entity (`Decision`) | Decisions need structured lifecycle and supersession |
|
||||
| Requirement | Future AtoCore entity (`Requirement`) | Requirements need structured management |
|
||||
| Constraint | Future AtoCore entity (`Constraint`) | Constraints need structured management |
|
||||
| Current trusted project answer | AtoCore `project_state` | This layer is explicitly for current trusted truth |
|
||||
| Project registration metadata | AtoCore project registry | Registry state is its own canonical operator layer |
|
||||
| Review action (promote / reject / invalidate) | AtoCore audit trail / operator action log | Review decisions are operator events, not source facts |
|
||||
|
||||
## What this means for Discord-originated facts
|
||||
|
||||
A Discord-originated signal can end in more than one place, but not directly.
|
||||
|
||||
### If the signal is conversational, ambiguous, or historical
|
||||
|
||||
It stays in the evidence lane:
|
||||
|
||||
- Discord
|
||||
- Discrawl archive
|
||||
- optional screener artifact
|
||||
- optional candidate queue
|
||||
|
||||
It does not become trusted project_state.
|
||||
|
||||
### If the signal is a stable personal or episodic fact
|
||||
|
||||
It may be promoted to AtoCore memory after review.
|
||||
|
||||
Examples:
|
||||
|
||||
- "Antoine prefers concise operator summaries."
|
||||
- "We decided in discussion to keep AtoCore additive."
|
||||
|
||||
These belong in reviewed memory, not in project_state.
|
||||
|
||||
### If the signal expresses a structured engineering fact
|
||||
|
||||
It may become an entity candidate and later an active entity.
|
||||
|
||||
Examples:
|
||||
|
||||
- a requirement
|
||||
- a decision
|
||||
- a constraint
|
||||
|
||||
Again, not directly from raw chat. The chat is evidence for the candidate.
|
||||
|
||||
### If the signal is the current trusted answer
|
||||
|
||||
It still should not jump directly from Discord into project_state.
|
||||
Instead, a human should explicitly curate it into project_state after checking it against the right canonical home.
|
||||
|
||||
That canonical home may be:
|
||||
|
||||
- PKM for prose and project notes
|
||||
- repo for code and design docs
|
||||
- KB tools for structured engineering facts
|
||||
- active entity if the engineering layer is the canonical home
|
||||
|
||||
## Approval boundaries
|
||||
|
||||
### Reads
|
||||
|
||||
The following may be invoked automatically when useful:
|
||||
|
||||
- `health`
|
||||
- `projects`
|
||||
- `detect-project`
|
||||
- `auto-context`
|
||||
- `query`
|
||||
- `project-state` read
|
||||
- Discrawl retrieval
|
||||
|
||||
These are additive and fail-open.
|
||||
|
||||
### Mutations requiring explicit human approval
|
||||
|
||||
The following are operator actions, not conversational automation:
|
||||
|
||||
- `register-project`
|
||||
- `update-project`
|
||||
- `refresh-project`
|
||||
- `ingest-sources`
|
||||
- `project-state-set`
|
||||
- `project-state-invalidate`
|
||||
- `capture` when used as a durable write outside conservative logging policy
|
||||
- `extract` with persistence
|
||||
- `promote`
|
||||
- `reject`
|
||||
- future entity promotion or rejection
|
||||
|
||||
For Discord-originated paths, approval must satisfy the explicit approval rule above.
|
||||
|
||||
## Shared operator client rule
|
||||
|
||||
The preferred V1 architecture is:
|
||||
|
||||
- AtoCore HTTP API as system interface
|
||||
- shared operator client as reusable mutating surface
|
||||
- OpenClaw as a thin frontend and operator around that client
|
||||
|
||||
That avoids duplicating:
|
||||
|
||||
- project detection logic
|
||||
- request logic
|
||||
- failure handling
|
||||
- mutation surface behavior
|
||||
- approval wrappers
|
||||
|
||||
OpenClaw should keep its own high-level operating instructions, but it should not keep growing a parallel AtoCore mutation implementation.
|
||||
|
||||
## V1 boundary summary
|
||||
|
||||
### Allowed automatic behavior
|
||||
|
||||
- read-only retrieval
|
||||
- context build
|
||||
- Discrawl recall
|
||||
- evidence collection
|
||||
- nightly screening into reviewable output
|
||||
- fail-open fallback when AtoCore is unavailable
|
||||
|
||||
### Allowed only after explicit human review or approval
|
||||
|
||||
- candidate persistence from evidence
|
||||
- candidate promotion or rejection
|
||||
- project refresh or ingestion
|
||||
- registry mutation
|
||||
- trusted project_state writes
|
||||
|
||||
### Not allowed as automatic behavior
|
||||
|
||||
- direct Discord -> project_state writes
|
||||
- direct Discord -> register / update / refresh / ingest / promote / reject
|
||||
- hidden mutation inside the screener
|
||||
- treating PKM as the main operator-instruction layer for AtoCore behavior
|
||||
|
||||
## Deferred from V1
|
||||
|
||||
Screenpipe is deferred.
|
||||
It is not an active input lane in V1 and it must not become a runtime, skill, or policy dependency in V1.
|
||||
If it is revisited later, it must be treated as a separate future design decision, not as an implicit V1 extension.
|
||||
|
||||
## Bottom line
|
||||
|
||||
The safe V1 architecture is not "everything can write into AtoCore."
|
||||
It is a layered system where:
|
||||
|
||||
- evidence comes in broadly
|
||||
- trust rises slowly
|
||||
- canonical homes stay singular
|
||||
- OpenClaw remains the operator
|
||||
- AtoCore remains the additive machine-memory and trusted-state layer
|
||||
- the shared operator client becomes the one reusable write-capable surface
|
||||
@@ -1,207 +0,0 @@
|
||||
# OpenClaw x AtoCore V1 Proof Runbook
|
||||
|
||||
## Purpose
|
||||
|
||||
This is the concise proof and operator runbook for the final V1 policy.
|
||||
It shows, in concrete paths, that:
|
||||
|
||||
- a Discord-originated signal cannot reach `project_state` without candidate or review gating
|
||||
- Discord cannot directly execute `register-project`, `update-project`, `refresh-project`, `ingest-sources`, `promote`, or `reject` without explicit approval
|
||||
|
||||
## Explicit approval definition
|
||||
|
||||
For V1, explicit approval means:
|
||||
|
||||
- the human directly instructs the specific mutating action
|
||||
- the instruction is in the current thread or current session
|
||||
- the approval is for that exact action
|
||||
- the approval is not inferred from evidence, archives, or screener output
|
||||
|
||||
Examples:
|
||||
|
||||
- "refresh p05 now"
|
||||
- "register this project"
|
||||
- "promote that candidate"
|
||||
- "write this to project_state"
|
||||
|
||||
Non-examples:
|
||||
|
||||
- "this looks like the current answer"
|
||||
- "we should probably refresh this"
|
||||
- an old Discord thread saying a refresh might help
|
||||
- a screener report recommending a mutation
|
||||
|
||||
## Proof 1 - Discord cannot directly reach project_state
|
||||
|
||||
Blocked path:
|
||||
|
||||
```text
|
||||
Discord message
|
||||
-> evidence
|
||||
-> optional candidate
|
||||
-> review
|
||||
-> optional explicit curation
|
||||
-> project_state
|
||||
```
|
||||
|
||||
What is blocked:
|
||||
|
||||
- Discord -> project_state directly
|
||||
- Discrawl archive -> project_state directly
|
||||
- screener output -> project_state directly
|
||||
|
||||
What is allowed:
|
||||
|
||||
1. Discord message enters the evidence lane.
|
||||
2. It may become a memory or entity candidate after screening.
|
||||
3. A human reviews the candidate.
|
||||
4. If the fact is truly the current trusted answer, the human may explicitly curate it into `project_state`.
|
||||
|
||||
Conclusion:
|
||||
|
||||
`project_state` is reachable only after review and explicit curation. There is no direct Discord-originated write path.
|
||||
|
||||
## Proof 2 - Discord cannot directly execute mutating operator actions
|
||||
|
||||
Blocked direct actions:
|
||||
|
||||
- `register-project`
|
||||
- `update-project`
|
||||
- `refresh-project`
|
||||
- `ingest-sources`
|
||||
- `promote`
|
||||
- `reject`
|
||||
- `project-state-set`
|
||||
- `project-state-invalidate`
|
||||
|
||||
Blocked path:
|
||||
|
||||
```text
|
||||
Discord message
|
||||
-> evidence or operator request context
|
||||
-X-> direct mutation
|
||||
```
|
||||
|
||||
Allowed path:
|
||||
|
||||
```text
|
||||
Discord message
|
||||
-> OpenClaw recognizes requested operator action
|
||||
-> explicit approval check
|
||||
-> approved operator action
|
||||
-> shared operator client or helper call
|
||||
```
|
||||
|
||||
Conclusion:
|
||||
|
||||
Discord can request or justify a mutation, but it cannot perform it on its own.
|
||||
|
||||
## Proof 3 - Discrawl does not create approval
|
||||
|
||||
Discrawl is evidence retrieval.
|
||||
It may surface:
|
||||
|
||||
- prior discussions
|
||||
- earlier decisions
|
||||
- unresolved questions
|
||||
- prior suggestions to mutate state
|
||||
|
||||
It does not create approval for mutation.
|
||||
|
||||
Blocked path:
|
||||
|
||||
```text
|
||||
Discrawl recall
|
||||
-X-> refresh-project
|
||||
-X-> promote
|
||||
-X-> project_state write
|
||||
```
|
||||
|
||||
Allowed path:
|
||||
|
||||
```text
|
||||
Discrawl recall
|
||||
-> evidence for human review
|
||||
-> explicit approval in current thread/session if mutation is desired
|
||||
-> approved operator action
|
||||
```
|
||||
|
||||
Conclusion:
|
||||
|
||||
Archive recall informs review. It does not authorize writes.
|
||||
|
||||
## Proof 4 - Screener has no hidden mutation lane
|
||||
|
||||
The screener may:
|
||||
|
||||
- gather evidence
|
||||
- classify evidence
|
||||
- prepare candidates
|
||||
- prepare operator queues
|
||||
- report contradictions or missing context
|
||||
|
||||
The screener may not:
|
||||
|
||||
- write `project_state`
|
||||
- mutate registry state
|
||||
- refresh or ingest directly
|
||||
- promote or reject directly
|
||||
|
||||
Blocked path:
|
||||
|
||||
```text
|
||||
screener output
|
||||
-X-> hidden mutation
|
||||
```
|
||||
|
||||
Allowed path:
|
||||
|
||||
```text
|
||||
screener output
|
||||
-> review queue or operator queue
|
||||
-> explicit approval if mutation is wanted
|
||||
-> approved operator action
|
||||
```
|
||||
|
||||
Conclusion:
|
||||
|
||||
The screener is a filter, not a hidden writer.
|
||||
|
||||
## Minimal operator decision table
|
||||
|
||||
| Situation | Allowed next step | Blocked next step |
|
||||
|---|---|---|
|
||||
| Discord says "this is the current answer" | evidence, then review, then possible explicit curation | direct `project_state` write |
|
||||
| Discord says "refresh p05" without direct instruction | ask for explicit approval | direct `refresh-project` |
|
||||
| Discord says "refresh p05 now" | approved operator action may run | none, if approval is explicit |
|
||||
| Discrawl finds an old thread asking for registration | use as review context only | direct `register-project` |
|
||||
| Screener recommends promotion | ask for explicit review decision | direct `promote` |
|
||||
|
||||
## Practical runbook
|
||||
|
||||
### Case A - current-truth claim from Discord
|
||||
|
||||
1. Treat the message as evidence.
|
||||
2. Check the canonical home.
|
||||
3. If needed, prepare a candidate or review note.
|
||||
4. Do not write `project_state` unless the human explicitly approves that curation step.
|
||||
|
||||
### Case B - requested refresh from Discord
|
||||
|
||||
1. Determine whether the message is a direct instruction or only discussion.
|
||||
2. If not explicit, ask for approval.
|
||||
3. Only perform `refresh-project` after explicit approval in the current thread or session.
|
||||
|
||||
### Case C - candidate promotion request
|
||||
|
||||
1. Candidate exists or is proposed.
|
||||
2. Review the evidence and the candidate text.
|
||||
3. Only perform `promote` or `reject` after explicit review decision.
|
||||
|
||||
## Bottom line
|
||||
|
||||
The V1 rule is easy to test:
|
||||
|
||||
If the path starts from Discord or Discrawl and ends in trusted or operator state, there must be a visible approval or review step in the middle.
|
||||
|
||||
If that visible step is missing, the action is not allowed.
|
||||
@@ -1,184 +0,0 @@
|
||||
# OpenClaw x AtoCore V1 Write-Policy Matrix
|
||||
|
||||
## Purpose
|
||||
|
||||
This matrix defines what each source is allowed to write to each target in V1.
|
||||
|
||||
Policy meanings:
|
||||
|
||||
- `auto-write` = allowed automatically without a human approval gate
|
||||
- `candidate-only` = may create reviewable candidate material, but not active truth
|
||||
- `human-review` = allowed only after explicit human review or explicit human approval
|
||||
- `never-auto-write` = never allowed as an automatic write path
|
||||
|
||||
## Explicit approval rule
|
||||
|
||||
In this matrix, `human-review` is concrete, not vague.
|
||||
For Discord-originated or Discrawl-originated paths it means:
|
||||
|
||||
- the human directly instructs the specific mutating action
|
||||
- the instruction is in the current thread or current session
|
||||
- the approval is for that specific action
|
||||
- the approval is not inferred from evidence, archives, screener output, or general discussion
|
||||
|
||||
Examples of explicit approval:
|
||||
|
||||
- "refresh p05 now"
|
||||
- "register this project"
|
||||
- "promote this candidate"
|
||||
- "write this to project_state"
|
||||
|
||||
Non-examples:
|
||||
|
||||
- "this looks important"
|
||||
- "we should probably refresh this"
|
||||
- archived discussion that once mentioned a similar mutation
|
||||
- a screener note recommending promotion
|
||||
|
||||
## V1 scope note
|
||||
|
||||
V1 active inputs are:
|
||||
|
||||
- Discord and Discrawl
|
||||
- OpenClaw interaction evidence
|
||||
- PKM, repos, and KB sources
|
||||
- read-only AtoCore context for comparison and deduplication
|
||||
|
||||
## Targets
|
||||
|
||||
The targets below are the only ones that matter for this policy.
|
||||
|
||||
- Evidence artifacts
|
||||
- Memory candidates
|
||||
- Active memories
|
||||
- Entity candidates
|
||||
- Active entities
|
||||
- Trusted project_state
|
||||
- Registry / refresh / ingest mutations
|
||||
- Review actions
|
||||
|
||||
## Matrix
|
||||
|
||||
| Source | Target | Policy | Notes / gate |
|
||||
|---|---|---|---|
|
||||
| Discord live message | Evidence artifacts | auto-write | Safe evidence capture or archive only |
|
||||
| Discord live message | Memory candidates | candidate-only | Only after screening or extraction; never direct active write |
|
||||
| Discord live message | Active memories | human-review | Promote only after review of the candidate and evidence |
|
||||
| Discord live message | Entity candidates | candidate-only | Only when structured signal is extracted from evidence |
|
||||
| Discord live message | Active entities | human-review | Review required before promotion |
|
||||
| Discord live message | Trusted project_state | human-review | Only via explicit curation; never directly from raw chat |
|
||||
| Discord live message | Registry / refresh / ingest mutations | human-review | Requires explicit approval in the current thread or session |
|
||||
| Discord live message | Review actions | human-review | Discord cannot silently promote or reject on its own |
|
||||
| Discrawl archive result | Evidence artifacts | auto-write | Archive or search result is evidence by design |
|
||||
| Discrawl archive result | Memory candidates | candidate-only | Extract reviewed signal from archived conversation |
|
||||
| Discrawl archive result | Active memories | human-review | Promotion required |
|
||||
| Discrawl archive result | Entity candidates | candidate-only | Archived discussion may justify candidate creation |
|
||||
| Discrawl archive result | Active entities | human-review | Promotion required |
|
||||
| Discrawl archive result | Trusted project_state | human-review | Must be explicitly curated; never inferred directly from archive |
|
||||
| Discrawl archive result | Registry / refresh / ingest mutations | human-review | Archive recall cannot directly mutate operator state |
|
||||
| Discrawl archive result | Review actions | human-review | Archive evidence informs review; it does not perform review |
|
||||
| OpenClaw read/query flow | Evidence artifacts | auto-write | Conservative interaction or evidence logging is acceptable |
|
||||
| OpenClaw read/query flow | Memory candidates | candidate-only | Only through explicit extraction path |
|
||||
| OpenClaw read/query flow | Active memories | human-review | Requires operator review |
|
||||
| OpenClaw read/query flow | Entity candidates | candidate-only | Future extraction path |
|
||||
| OpenClaw read/query flow | Active entities | human-review | Requires operator review |
|
||||
| OpenClaw read/query flow | Trusted project_state | never-auto-write | Read/query flow must stay additive |
|
||||
| OpenClaw read/query flow | Registry / refresh / ingest mutations | never-auto-write | Read/query automation must not mutate operator state |
|
||||
| OpenClaw read/query flow | Review actions | never-auto-write | Read automation cannot silently promote or reject |
|
||||
| OpenClaw approved operator action | Evidence artifacts | auto-write | May create operator or audit artifacts |
|
||||
| OpenClaw approved operator action | Memory candidates | human-review | Candidate persistence is itself an approved operator action |
|
||||
| OpenClaw approved operator action | Active memories | human-review | Promotion allowed only through reviewed operator action |
|
||||
| OpenClaw approved operator action | Entity candidates | human-review | Same rule for future entities |
|
||||
| OpenClaw approved operator action | Active entities | human-review | Promotion allowed only through reviewed operator action |
|
||||
| OpenClaw approved operator action | Trusted project_state | human-review | Allowed only as explicit curation |
|
||||
| OpenClaw approved operator action | Registry / refresh / ingest mutations | human-review | Explicit approval required |
|
||||
| OpenClaw approved operator action | Review actions | human-review | Explicit review required |
|
||||
| PKM note | Evidence artifacts | human-review | Snapshotting into evidence is optional, not the primary path |
|
||||
| PKM note | Memory candidates | candidate-only | Extraction from PKM is allowed into the candidate lane |
|
||||
| PKM note | Active memories | human-review | Promotion required |
|
||||
| PKM note | Entity candidates | candidate-only | Extract structured signal into the candidate lane |
|
||||
| PKM note | Active entities | human-review | Promotion required |
|
||||
| PKM note | Trusted project_state | human-review | Only via explicit curation of current truth |
|
||||
| PKM note | Registry / refresh / ingest mutations | human-review | A human may choose to refresh based on PKM changes |
|
||||
| PKM note | Review actions | human-review | PKM may support the decision, but not execute it automatically |
|
||||
| Repo / KB source | Evidence artifacts | human-review | Optional audit or screener snapshot only |
|
||||
| Repo / KB source | Memory candidates | candidate-only | Extract loose durable signal if useful |
|
||||
| Repo / KB source | Active memories | human-review | Promotion required |
|
||||
| Repo / KB source | Entity candidates | candidate-only | Strong future path for structured facts |
|
||||
| Repo / KB source | Active entities | human-review | Promotion required |
|
||||
| Repo / KB source | Trusted project_state | human-review | Explicit curation only |
|
||||
| Repo / KB source | Registry / refresh / ingest mutations | human-review | A human may refresh or ingest based on source changes |
|
||||
| Repo / KB source | Review actions | human-review | Source can justify review; it does not perform review |
|
||||
| AtoCore active memory | Evidence artifacts | never-auto-write | Active memory is already above the evidence layer |
|
||||
| AtoCore active memory | Memory candidates | never-auto-write | Do not recursively re-candidate active memory |
|
||||
| AtoCore active memory | Active memories | never-auto-write | Already active |
|
||||
| AtoCore active memory | Entity candidates | human-review | Graduation proposal only with review |
|
||||
| AtoCore active memory | Active entities | human-review | Requires graduation plus promotion |
|
||||
| AtoCore active memory | Trusted project_state | human-review | A human may explicitly curate current truth from memory |
|
||||
| AtoCore active memory | Registry / refresh / ingest mutations | never-auto-write | Memory must not mutate registry or ingestion state |
|
||||
| AtoCore active memory | Review actions | human-review | Human reviewer decides |
|
||||
| AtoCore active entity | Evidence artifacts | never-auto-write | Already above the evidence layer |
|
||||
| AtoCore active entity | Memory candidates | never-auto-write | Do not backflow structured truth into memory candidates automatically |
|
||||
| AtoCore active entity | Active memories | never-auto-write | Canonical home is the entity, not a new memory |
|
||||
| AtoCore active entity | Entity candidates | never-auto-write | Already active |
|
||||
| AtoCore active entity | Active entities | never-auto-write | Already active |
|
||||
| AtoCore active entity | Trusted project_state | human-review | Explicit curation may publish the current trusted answer |
|
||||
| AtoCore active entity | Registry / refresh / ingest mutations | never-auto-write | Entities do not operate the registry |
|
||||
| AtoCore active entity | Review actions | human-review | Human reviewer decides |
|
||||
|
||||
## Discord-originated trace examples
|
||||
|
||||
### Example 1 - conversational decision in Discord
|
||||
|
||||
Allowed path:
|
||||
|
||||
1. Discord live message -> Evidence artifacts (`auto-write`)
|
||||
2. Evidence artifacts -> Memory candidates or Entity candidates (`candidate-only`)
|
||||
3. Candidate -> Active memory or Active entity (`human-review`)
|
||||
4. If it becomes the current trusted answer, a human may explicitly curate it into Trusted project_state (`human-review`)
|
||||
|
||||
There is no direct Discord -> project_state automatic path.
|
||||
|
||||
### Example 2 - archived Discord thread via Discrawl
|
||||
|
||||
Allowed path:
|
||||
|
||||
1. Discrawl result -> Evidence artifacts (`auto-write`)
|
||||
2. Discrawl result -> Memory candidates or Entity candidates (`candidate-only`)
|
||||
3. Human review decides promotion
|
||||
4. Optional explicit curation into project_state later
|
||||
|
||||
Again, there is no direct archive -> trusted truth path.
|
||||
|
||||
### Example 3 - Discord request to refresh a project
|
||||
|
||||
Allowed path:
|
||||
|
||||
1. Discord message is evidence of requested operator intent
|
||||
2. No mutation happens automatically
|
||||
3. OpenClaw requires explicit approval in the current thread or session for `refresh-project`
|
||||
4. Only then may OpenClaw perform the approved operator action
|
||||
|
||||
There is no direct Discord -> refresh path without explicit approval.
|
||||
|
||||
## V1 interpretation rules
|
||||
|
||||
1. Evidence can flow in broadly.
|
||||
2. Truth can only rise through review.
|
||||
3. project_state is the narrowest lane.
|
||||
4. Registry and ingestion operations are operator actions, not evidence effects.
|
||||
5. Discord-originated paths can inform operator actions, but they cannot silently execute them.
|
||||
6. Deferred sources that are out of V1 scope have no automatic or manual role in this V1 matrix.
|
||||
|
||||
## Deferred from V1
|
||||
|
||||
Screenpipe is deferred and intentionally omitted from this V1 matrix.
|
||||
|
||||
## Bottom line
|
||||
|
||||
If a source is noisy, conversational, or archived, its maximum automatic privilege in V1 is:
|
||||
|
||||
- evidence capture, or
|
||||
- candidate creation
|
||||
|
||||
Everything above that requires explicit human review or explicit human approval.
|
||||
247
scripts/auto_triage.py
Normal file
247
scripts/auto_triage.py
Normal file
@@ -0,0 +1,247 @@
|
||||
"""Auto-triage: LLM second-pass over candidate memories.
|
||||
|
||||
Fetches all status=candidate memories from the AtoCore API, asks
|
||||
a triage model (via claude -p) to classify each as promote / reject /
|
||||
needs_human, and executes the verdict via the promote/reject endpoints.
|
||||
Only needs_human candidates remain in the queue for manual review.
|
||||
|
||||
Trust model:
|
||||
- Auto-promote: model says promote AND confidence >= 0.8 AND no
|
||||
duplicate content in existing active memories
|
||||
- Auto-reject: model says reject
|
||||
- needs_human: everything else stays in queue
|
||||
|
||||
Runs host-side (same as batch extraction) because it needs the
|
||||
claude CLI. Intended to be called after batch-extract.sh in the
|
||||
nightly cron, or manually.
|
||||
|
||||
Usage:
|
||||
|
||||
python3 scripts/auto_triage.py --base-url http://localhost:8100
|
||||
python3 scripts/auto_triage.py --dry-run # preview without executing
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
import os
|
||||
import shutil
|
||||
import subprocess
|
||||
import sys
|
||||
import tempfile
|
||||
import urllib.error
|
||||
import urllib.parse
|
||||
import urllib.request
|
||||
|
||||
DEFAULT_BASE_URL = os.environ.get("ATOCORE_BASE_URL", "http://localhost:8100")
|
||||
DEFAULT_MODEL = os.environ.get("ATOCORE_TRIAGE_MODEL", "sonnet")
|
||||
DEFAULT_TIMEOUT_S = float(os.environ.get("ATOCORE_TRIAGE_TIMEOUT_S", "60"))
|
||||
AUTO_PROMOTE_MIN_CONFIDENCE = 0.8
|
||||
|
||||
TRIAGE_SYSTEM_PROMPT = """You are a memory triage reviewer for a personal context engine called AtoCore. You review candidate memories extracted from LLM conversations and decide whether each should be promoted to active status, rejected, or flagged for human review.
|
||||
|
||||
You will receive:
|
||||
- The candidate memory content and type
|
||||
- A list of existing active memories for the same project (to check for duplicates)
|
||||
|
||||
For each candidate, output exactly one JSON object:
|
||||
|
||||
{"verdict": "promote|reject|needs_human", "confidence": 0.0-1.0, "reason": "one sentence"}
|
||||
|
||||
Rules:
|
||||
|
||||
1. PROMOTE when the candidate states a durable architectural fact, ratified decision, standing rule, or engineering constraint that is NOT already covered by an existing active memory. Confidence should reflect how certain you are this is worth keeping.
|
||||
|
||||
2. REJECT when the candidate is:
|
||||
- A stale point-in-time snapshot ("live SHA is X", "36 active memories")
|
||||
- An implementation detail too granular to be useful as standalone context
|
||||
- A planned-but-not-implemented feature description
|
||||
- A duplicate or near-duplicate of an existing active memory
|
||||
- A session observation or conversational filler
|
||||
- A process rule that belongs in DEV-LEDGER.md or AGENTS.md, not memory
|
||||
|
||||
3. NEEDS_HUMAN when you're genuinely unsure — the candidate might be valuable but you can't tell without domain knowledge. This should be rare (< 20% of candidates).
|
||||
|
||||
4. Output ONLY the JSON object. No prose, no markdown, no explanation outside the reason field."""
|
||||
|
||||
_sandbox_cwd = None
|
||||
|
||||
|
||||
def get_sandbox_cwd():
|
||||
global _sandbox_cwd
|
||||
if _sandbox_cwd is None:
|
||||
_sandbox_cwd = tempfile.mkdtemp(prefix="ato-triage-")
|
||||
return _sandbox_cwd
|
||||
|
||||
|
||||
def api_get(base_url, path, timeout=10):
|
||||
req = urllib.request.Request(f"{base_url}{path}")
|
||||
with urllib.request.urlopen(req, timeout=timeout) as resp:
|
||||
return json.loads(resp.read().decode("utf-8"))
|
||||
|
||||
|
||||
def api_post(base_url, path, body=None, timeout=10):
|
||||
data = json.dumps(body or {}).encode("utf-8")
|
||||
req = urllib.request.Request(
|
||||
f"{base_url}{path}", method="POST",
|
||||
headers={"Content-Type": "application/json"}, data=data,
|
||||
)
|
||||
with urllib.request.urlopen(req, timeout=timeout) as resp:
|
||||
return json.loads(resp.read().decode("utf-8"))
|
||||
|
||||
|
||||
def fetch_active_memories_for_project(base_url, project):
|
||||
"""Fetch active memories for dedup checking."""
|
||||
params = "active_only=true&limit=50"
|
||||
if project:
|
||||
params += f"&project={urllib.parse.quote(project)}"
|
||||
result = api_get(base_url, f"/memory?{params}")
|
||||
return result.get("memories", [])
|
||||
|
||||
|
||||
def triage_one(candidate, active_memories, model, timeout_s):
|
||||
"""Ask the triage model to classify one candidate."""
|
||||
if not shutil.which("claude"):
|
||||
return {"verdict": "needs_human", "confidence": 0.0, "reason": "claude CLI not available"}
|
||||
|
||||
active_summary = "\n".join(
|
||||
f"- [{m['memory_type']}] {m['content'][:150]}"
|
||||
for m in active_memories[:20]
|
||||
) or "(no active memories for this project)"
|
||||
|
||||
user_message = (
|
||||
f"CANDIDATE TO TRIAGE:\n"
|
||||
f" type: {candidate['memory_type']}\n"
|
||||
f" project: {candidate.get('project') or '(none)'}\n"
|
||||
f" content: {candidate['content']}\n\n"
|
||||
f"EXISTING ACTIVE MEMORIES FOR THIS PROJECT:\n{active_summary}\n\n"
|
||||
f"Return the JSON verdict now."
|
||||
)
|
||||
|
||||
args = [
|
||||
"claude", "-p",
|
||||
"--model", model,
|
||||
"--append-system-prompt", TRIAGE_SYSTEM_PROMPT,
|
||||
"--disable-slash-commands",
|
||||
user_message,
|
||||
]
|
||||
|
||||
try:
|
||||
completed = subprocess.run(
|
||||
args, capture_output=True, text=True,
|
||||
timeout=timeout_s, cwd=get_sandbox_cwd(),
|
||||
encoding="utf-8", errors="replace",
|
||||
)
|
||||
except subprocess.TimeoutExpired:
|
||||
return {"verdict": "needs_human", "confidence": 0.0, "reason": "triage model timed out"}
|
||||
except Exception as exc:
|
||||
return {"verdict": "needs_human", "confidence": 0.0, "reason": f"subprocess error: {exc}"}
|
||||
|
||||
if completed.returncode != 0:
|
||||
return {"verdict": "needs_human", "confidence": 0.0, "reason": f"claude exit {completed.returncode}"}
|
||||
|
||||
raw = (completed.stdout or "").strip()
|
||||
return parse_verdict(raw)
|
||||
|
||||
|
||||
def parse_verdict(raw):
|
||||
"""Parse the triage model's JSON verdict."""
|
||||
text = raw.strip()
|
||||
if text.startswith("```"):
|
||||
text = text.strip("`")
|
||||
nl = text.find("\n")
|
||||
if nl >= 0:
|
||||
text = text[nl + 1:]
|
||||
if text.endswith("```"):
|
||||
text = text[:-3]
|
||||
text = text.strip()
|
||||
|
||||
if not text.lstrip().startswith("{"):
|
||||
start = text.find("{")
|
||||
end = text.rfind("}")
|
||||
if start >= 0 and end > start:
|
||||
text = text[start:end + 1]
|
||||
|
||||
try:
|
||||
parsed = json.loads(text)
|
||||
except json.JSONDecodeError:
|
||||
return {"verdict": "needs_human", "confidence": 0.0, "reason": "failed to parse triage output"}
|
||||
|
||||
verdict = str(parsed.get("verdict", "needs_human")).strip().lower()
|
||||
if verdict not in {"promote", "reject", "needs_human"}:
|
||||
verdict = "needs_human"
|
||||
|
||||
confidence = parsed.get("confidence", 0.5)
|
||||
try:
|
||||
confidence = max(0.0, min(1.0, float(confidence)))
|
||||
except (TypeError, ValueError):
|
||||
confidence = 0.5
|
||||
|
||||
reason = str(parsed.get("reason", "")).strip()[:200]
|
||||
return {"verdict": verdict, "confidence": confidence, "reason": reason}
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(description="Auto-triage candidate memories")
|
||||
parser.add_argument("--base-url", default=DEFAULT_BASE_URL)
|
||||
parser.add_argument("--model", default=DEFAULT_MODEL)
|
||||
parser.add_argument("--dry-run", action="store_true", help="preview without executing")
|
||||
args = parser.parse_args()
|
||||
|
||||
# Fetch candidates
|
||||
result = api_get(args.base_url, "/memory?status=candidate&limit=100")
|
||||
candidates = result.get("memories", [])
|
||||
print(f"candidates: {len(candidates)} model: {args.model} dry_run: {args.dry_run}")
|
||||
|
||||
if not candidates:
|
||||
print("queue empty, nothing to triage")
|
||||
return
|
||||
|
||||
# Cache active memories per project for dedup
|
||||
active_cache = {}
|
||||
promoted = rejected = needs_human = errors = 0
|
||||
|
||||
for i, cand in enumerate(candidates, 1):
|
||||
project = cand.get("project") or ""
|
||||
if project not in active_cache:
|
||||
active_cache[project] = fetch_active_memories_for_project(args.base_url, project)
|
||||
|
||||
verdict_obj = triage_one(cand, active_cache[project], args.model, DEFAULT_TIMEOUT_S)
|
||||
verdict = verdict_obj["verdict"]
|
||||
conf = verdict_obj["confidence"]
|
||||
reason = verdict_obj["reason"]
|
||||
|
||||
mid = cand["id"]
|
||||
label = f"[{i:2d}/{len(candidates)}] {mid[:8]} [{cand['memory_type']}]"
|
||||
|
||||
if verdict == "promote" and conf >= AUTO_PROMOTE_MIN_CONFIDENCE:
|
||||
if args.dry_run:
|
||||
print(f" WOULD PROMOTE {label} conf={conf:.2f} {reason}")
|
||||
else:
|
||||
try:
|
||||
api_post(args.base_url, f"/memory/{mid}/promote")
|
||||
print(f" PROMOTED {label} conf={conf:.2f} {reason}")
|
||||
active_cache[project].append(cand)
|
||||
except Exception:
|
||||
errors += 1
|
||||
promoted += 1
|
||||
elif verdict == "reject":
|
||||
if args.dry_run:
|
||||
print(f" WOULD REJECT {label} conf={conf:.2f} {reason}")
|
||||
else:
|
||||
try:
|
||||
api_post(args.base_url, f"/memory/{mid}/reject")
|
||||
print(f" REJECTED {label} conf={conf:.2f} {reason}")
|
||||
except Exception:
|
||||
errors += 1
|
||||
rejected += 1
|
||||
else:
|
||||
print(f" NEEDS_HUMAN {label} conf={conf:.2f} {reason}")
|
||||
needs_human += 1
|
||||
|
||||
print(f"\npromoted={promoted} rejected={rejected} needs_human={needs_human} errors={errors}")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
300
scripts/batch_llm_extract_live.py
Normal file
300
scripts/batch_llm_extract_live.py
Normal file
@@ -0,0 +1,300 @@
|
||||
"""Host-side LLM batch extraction — pure HTTP client, no atocore imports.
|
||||
|
||||
Fetches interactions from the AtoCore API, runs ``claude -p`` locally
|
||||
for each, and POSTs candidates back. Zero dependency on atocore source
|
||||
or Python packages — only uses stdlib + the ``claude`` CLI on PATH.
|
||||
|
||||
This is necessary because the ``claude`` CLI is on the Dalidou HOST
|
||||
but not inside the Docker container, and the host's Python doesn't
|
||||
have the container's dependencies (pydantic_settings, etc.).
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import json
|
||||
import os
|
||||
import shutil
|
||||
import subprocess
|
||||
import sys
|
||||
import tempfile
|
||||
import urllib.error
|
||||
import urllib.parse
|
||||
import urllib.request
|
||||
from datetime import datetime, timezone
|
||||
|
||||
DEFAULT_BASE_URL = os.environ.get("ATOCORE_BASE_URL", "http://localhost:8100")
|
||||
DEFAULT_MODEL = os.environ.get("ATOCORE_LLM_EXTRACTOR_MODEL", "sonnet")
|
||||
DEFAULT_TIMEOUT_S = float(os.environ.get("ATOCORE_LLM_EXTRACTOR_TIMEOUT_S", "90"))
|
||||
MAX_RESPONSE_CHARS = 8000
|
||||
MAX_PROMPT_CHARS = 2000
|
||||
|
||||
MEMORY_TYPES = {"identity", "preference", "project", "episodic", "knowledge", "adaptation"}
|
||||
|
||||
SYSTEM_PROMPT = """You extract durable memory candidates from LLM conversation turns for a personal context engine called AtoCore.
|
||||
|
||||
Your job is to read one user prompt plus the assistant's response and decide which durable facts, decisions, preferences, architectural rules, or project invariants should be remembered across future sessions.
|
||||
|
||||
Rules:
|
||||
|
||||
1. Only surface durable claims. Skip transient status ("deploy is still running"), instructional guidance ("here is how to run the command"), troubleshooting tactics, ephemeral recommendations ("merge this PR now"), and session recaps.
|
||||
2. A candidate is durable when a reader coming back in two weeks would still need to know it. Architectural choices, named rules, ratified decisions, invariants, procurement commitments, and project-level constraints qualify. Conversational fillers and step-by-step instructions do not.
|
||||
3. Each candidate must stand alone. Rewrite the claim in one sentence under 200 characters with enough context that a reader without the conversation understands it.
|
||||
4. Each candidate must have a type from this closed set: project, knowledge, preference, adaptation.
|
||||
5. If the conversation is clearly scoped to a project (p04-gigabit, p05-interferometer, p06-polisher, atocore), set ``project`` to that id. Otherwise leave ``project`` empty.
|
||||
6. If the response makes no durable claim, return an empty list. It is correct and expected to return [] on most conversational turns.
|
||||
7. Confidence should be 0.5 by default so human review workload is honest. Raise to 0.6 only when the response states the claim in an unambiguous, committed form (e.g. "the decision is X", "the selected approach is Y", "X is non-negotiable").
|
||||
8. Output must be a raw JSON array and nothing else. No prose before or after. No markdown fences. No explanations.
|
||||
|
||||
Each array element has exactly this shape:
|
||||
|
||||
{"type": "project|knowledge|preference|adaptation", "content": "...", "project": "...", "confidence": 0.5}
|
||||
|
||||
Return [] when there is nothing to extract."""
|
||||
|
||||
_sandbox_cwd = None
|
||||
|
||||
|
||||
def get_sandbox_cwd():
|
||||
global _sandbox_cwd
|
||||
if _sandbox_cwd is None:
|
||||
_sandbox_cwd = tempfile.mkdtemp(prefix="ato-llm-extract-")
|
||||
return _sandbox_cwd
|
||||
|
||||
|
||||
def api_get(base_url, path, timeout=10):
|
||||
req = urllib.request.Request(f"{base_url}{path}")
|
||||
with urllib.request.urlopen(req, timeout=timeout) as resp:
|
||||
return json.loads(resp.read().decode("utf-8"))
|
||||
|
||||
|
||||
def api_post(base_url, path, body, timeout=10):
|
||||
data = json.dumps(body).encode("utf-8")
|
||||
req = urllib.request.Request(
|
||||
f"{base_url}{path}", method="POST",
|
||||
headers={"Content-Type": "application/json"}, data=data,
|
||||
)
|
||||
with urllib.request.urlopen(req, timeout=timeout) as resp:
|
||||
return json.loads(resp.read().decode("utf-8"))
|
||||
|
||||
|
||||
def get_last_run(base_url):
|
||||
try:
|
||||
state = api_get(base_url, "/project/state/atocore?category=status")
|
||||
for entry in state.get("entries", []):
|
||||
if entry.get("key") == "last_extract_batch_run":
|
||||
return entry["value"]
|
||||
except Exception:
|
||||
pass
|
||||
return None
|
||||
|
||||
|
||||
def set_last_run(base_url, timestamp):
|
||||
try:
|
||||
api_post(base_url, "/project/state", {
|
||||
"project": "atocore", "category": "status",
|
||||
"key": "last_extract_batch_run", "value": timestamp,
|
||||
"source": "batch_llm_extract_live.py",
|
||||
})
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
|
||||
_known_projects: set[str] = set()
|
||||
|
||||
|
||||
def _load_known_projects(base_url):
|
||||
"""Fetch registered project IDs from the API for R9 validation."""
|
||||
global _known_projects
|
||||
try:
|
||||
data = api_get(base_url, "/projects")
|
||||
_known_projects = {p["id"] for p in data.get("projects", [])}
|
||||
for p in data.get("projects", []):
|
||||
for alias in p.get("aliases", []):
|
||||
_known_projects.add(alias)
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
|
||||
def extract_one(prompt, response, project, model, timeout_s):
|
||||
"""Run claude -p on one interaction, return parsed candidates."""
|
||||
if not shutil.which("claude"):
|
||||
return [], "claude_cli_missing"
|
||||
|
||||
prompt_excerpt = prompt[:MAX_PROMPT_CHARS]
|
||||
response_excerpt = response[:MAX_RESPONSE_CHARS]
|
||||
user_message = (
|
||||
f"PROJECT HINT (may be empty): {project}\n\n"
|
||||
f"USER PROMPT:\n{prompt_excerpt}\n\n"
|
||||
f"ASSISTANT RESPONSE:\n{response_excerpt}\n\n"
|
||||
"Return the JSON array now."
|
||||
)
|
||||
|
||||
args = [
|
||||
"claude", "-p",
|
||||
"--model", model,
|
||||
"--append-system-prompt", SYSTEM_PROMPT,
|
||||
"--disable-slash-commands",
|
||||
user_message,
|
||||
]
|
||||
|
||||
try:
|
||||
completed = subprocess.run(
|
||||
args, capture_output=True, text=True,
|
||||
timeout=timeout_s, cwd=get_sandbox_cwd(),
|
||||
encoding="utf-8", errors="replace",
|
||||
)
|
||||
except subprocess.TimeoutExpired:
|
||||
return [], "timeout"
|
||||
except Exception as exc:
|
||||
return [], f"subprocess_error: {exc}"
|
||||
|
||||
if completed.returncode != 0:
|
||||
return [], f"exit_{completed.returncode}"
|
||||
|
||||
raw = (completed.stdout or "").strip()
|
||||
return parse_candidates(raw, project), ""
|
||||
|
||||
|
||||
def parse_candidates(raw, interaction_project):
|
||||
"""Parse model JSON output into candidate dicts."""
|
||||
text = raw.strip()
|
||||
if text.startswith("```"):
|
||||
text = text.strip("`")
|
||||
nl = text.find("\n")
|
||||
if nl >= 0:
|
||||
text = text[nl + 1:]
|
||||
if text.endswith("```"):
|
||||
text = text[:-3]
|
||||
text = text.strip()
|
||||
|
||||
if not text or text == "[]":
|
||||
return []
|
||||
|
||||
if not text.lstrip().startswith("["):
|
||||
start = text.find("[")
|
||||
end = text.rfind("]")
|
||||
if start >= 0 and end > start:
|
||||
text = text[start:end + 1]
|
||||
|
||||
try:
|
||||
parsed = json.loads(text)
|
||||
except json.JSONDecodeError:
|
||||
return []
|
||||
|
||||
if not isinstance(parsed, list):
|
||||
return []
|
||||
|
||||
results = []
|
||||
for item in parsed:
|
||||
if not isinstance(item, dict):
|
||||
continue
|
||||
mem_type = str(item.get("type") or "").strip().lower()
|
||||
content = str(item.get("content") or "").strip()
|
||||
model_project = str(item.get("project") or "").strip()
|
||||
# R9 trust hierarchy: interaction scope always wins when set.
|
||||
# Model project only used for unscoped interactions + registered check.
|
||||
if interaction_project:
|
||||
project = interaction_project
|
||||
elif model_project and model_project in _known_projects:
|
||||
project = model_project
|
||||
else:
|
||||
project = ""
|
||||
conf = item.get("confidence", 0.5)
|
||||
if mem_type not in MEMORY_TYPES or not content:
|
||||
continue
|
||||
try:
|
||||
conf = max(0.0, min(1.0, float(conf)))
|
||||
except (TypeError, ValueError):
|
||||
conf = 0.5
|
||||
results.append({
|
||||
"memory_type": mem_type,
|
||||
"content": content[:1000],
|
||||
"project": project,
|
||||
"confidence": conf,
|
||||
})
|
||||
return results
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(description="Host-side LLM batch extraction")
|
||||
parser.add_argument("--base-url", default=DEFAULT_BASE_URL)
|
||||
parser.add_argument("--limit", type=int, default=50)
|
||||
parser.add_argument("--since", default=None)
|
||||
parser.add_argument("--model", default=DEFAULT_MODEL)
|
||||
args = parser.parse_args()
|
||||
|
||||
_load_known_projects(args.base_url)
|
||||
since = args.since or get_last_run(args.base_url)
|
||||
print(f"since={since or '(first run)'} limit={args.limit} model={args.model} known_projects={len(_known_projects)}")
|
||||
|
||||
params = [f"limit={args.limit}"]
|
||||
if since:
|
||||
params.append(f"since={urllib.parse.quote(since)}")
|
||||
listing = api_get(args.base_url, f"/interactions?{'&'.join(params)}")
|
||||
interaction_summaries = listing.get("interactions", [])
|
||||
print(f"listed {len(interaction_summaries)} interactions")
|
||||
|
||||
processed = 0
|
||||
total_candidates = 0
|
||||
total_persisted = 0
|
||||
errors = 0
|
||||
|
||||
for summary in interaction_summaries:
|
||||
resp_chars = summary.get("response_chars", 0) or 0
|
||||
if resp_chars < 50:
|
||||
continue
|
||||
iid = summary["id"]
|
||||
try:
|
||||
raw = api_get(
|
||||
args.base_url,
|
||||
f"/interactions/{urllib.parse.quote(iid, safe='')}",
|
||||
)
|
||||
except Exception as exc:
|
||||
print(f" ! {iid[:8]}: fetch failed: {exc}", file=sys.stderr)
|
||||
errors += 1
|
||||
continue
|
||||
response_text = raw.get("response", "") or ""
|
||||
if not response_text.strip() or len(response_text) < 50:
|
||||
continue
|
||||
|
||||
candidates, error = extract_one(
|
||||
prompt=raw.get("prompt", "") or "",
|
||||
response=response_text,
|
||||
project=raw.get("project", "") or "",
|
||||
model=args.model,
|
||||
timeout_s=DEFAULT_TIMEOUT_S,
|
||||
)
|
||||
|
||||
if error:
|
||||
print(f" ! {raw['id'][:8]}: {error}", file=sys.stderr)
|
||||
errors += 1
|
||||
continue
|
||||
|
||||
processed += 1
|
||||
total_candidates += len(candidates)
|
||||
|
||||
for c in candidates:
|
||||
try:
|
||||
api_post(args.base_url, "/memory", {
|
||||
"memory_type": c["memory_type"],
|
||||
"content": c["content"],
|
||||
"project": c["project"],
|
||||
"confidence": c["confidence"],
|
||||
"status": "candidate",
|
||||
})
|
||||
total_persisted += 1
|
||||
except urllib.error.HTTPError as exc:
|
||||
if exc.code != 400:
|
||||
errors += 1
|
||||
except Exception:
|
||||
errors += 1
|
||||
|
||||
now = datetime.now(timezone.utc).strftime("%Y-%m-%d %H:%M:%S")
|
||||
set_last_run(args.base_url, now)
|
||||
|
||||
print(f"processed={processed} candidates={total_candidates} persisted={total_persisted} errors={errors}")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
1
scripts/eval_data/candidate_queue_2026-04-12.json
Normal file
1
scripts/eval_data/candidate_queue_2026-04-12.json
Normal file
File diff suppressed because one or more lines are too long
29
scripts/eval_data/candidate_queue_2026-04-12.txt
Normal file
29
scripts/eval_data/candidate_queue_2026-04-12.txt
Normal file
@@ -0,0 +1,29 @@
|
||||
1. [project ] proj=atocore AtoCore extraction must stay off the hot capture path; batch endpoint only
|
||||
2. [project ] proj=atocore Auto-promote gate: confidence ≥0.8 AND no duplicate in active memories
|
||||
3. [project ] proj=atocore AtoCore LLM extraction pipeline deployed on Dalidou host, runs via cron at 03:00 UTC via scripts/batch_llm_extract_live.py
|
||||
4. [project ] proj=atocore LLM extractor runs host-side (not in container) because claude CLI not available in container environment
|
||||
5. [project ] proj=atocore Host-side extraction script scripts/batch_llm_extract_live.py uses pure stdlib, no atocore imports for deployment simplicity
|
||||
6. [project ] proj=atocore POST /admin/extract-batch accepts mode: rule|llm, POST /interactions/{id}/extract now mode-aware
|
||||
7. [knowledge ] proj=atocore claude CLI 2.0.60 removed --no-session-persistence flag, extraction sessions now persist in claude history
|
||||
8. [adaptation ] proj=atocore Durable memory extraction candidates must be <200 chars, stand-alone, typed as project|knowledge|preference|adaptation
|
||||
9. [adaptation ] proj=atocore Memory extraction confidence defaults to 0.5, raise to 0.6 only for unambiguous committed claims
|
||||
10. [project ] proj=atocore Live Dalidou is on commit 39d73e9, not e2895b5
|
||||
11. [project ] proj=atocore Live harness is reproducible at 16/18 PASS
|
||||
12. [project ] proj=atocore Live active memories count is 36
|
||||
13. [project ] proj=atocore Wave 2 project-state entries on live: p04=5, p05=6, p06=6
|
||||
14. [project ] proj=atocore R6 is fixed by commit 39d73e9
|
||||
15. [project ] proj=atocore R9: R6 fix only covers empty project fallback; wrong non-empty model project can still override known interaction scope
|
||||
16. [project ] proj=atocore R10: Phase 8 is baseline-complete but not primary-complete; OpenClaw client covers narrow read-oriented slice of API
|
||||
17. [project ] proj=atocore Phase 8 is decent baseline integration milestone but not primary-ready yet
|
||||
18. [project ] proj=atocore 4-step roadmap complete: extractor → harness → Wave 2 → OpenClaw
|
||||
19. [project ] proj=atocore Codex audit loop proven across two full round-trips in one session
|
||||
20. [project ] proj=atocore Session end state: 36 active memories, 17 project-state entries, 16/18 harness, 280 tests, main at 54d84b5
|
||||
21. [project ] proj=atocore AtoCore extraction stays off the hot capture path; LLM extraction runs as scheduled batch, not inline with POST /interactions.
|
||||
22. [project ] proj=atocore AtoCore auto-triage trust model: auto-promote only when confidence ≥0.8 AND no duplicate active memory; else needs_human.
|
||||
23. [project ] proj=atocore Multi-model triage: use different model for triage reviewer than extractor (sonnet for extract)
|
||||
24. [project ] proj=atocore R9 fix: when interaction has known project, prefer it over model's non-matching project unless model's is registered
|
||||
25. [project ] proj=atocore R7 ranking fix: add overlap-density as secondary signal (overlap_count / memory_token_count)
|
||||
26. [project ] proj=atocore Extraction pipeline skips interactions with response_chars < 50 to avoid low-signal content
|
||||
27. [project ] proj=atocore AtoCore triage uses independent model from extractor (extractor: sonnet, triage: different model or different prompt).
|
||||
28. [project ] proj=atocore AtoCore ranking scorer adds overlap-density (overlap_count / memory_tokens) as secondary signal to fix short-memory ranking.
|
||||
29. [project ] proj=atocore AtoCore project trust: when interaction has known project and model returns different project, prefer interaction's project unless
|
||||
@@ -35,6 +35,10 @@ from atocore.memory.extractor import (
|
||||
MemoryCandidate,
|
||||
extract_candidates_from_interaction,
|
||||
)
|
||||
from atocore.memory.extractor_llm import (
|
||||
LLM_EXTRACTOR_VERSION,
|
||||
extract_candidates_llm,
|
||||
)
|
||||
from atocore.memory.reinforcement import reinforce_from_interaction
|
||||
from atocore.memory.service import (
|
||||
MEMORY_STATUSES,
|
||||
@@ -580,6 +584,7 @@ def api_reinforce_interaction(interaction_id: str) -> dict:
|
||||
|
||||
class InteractionExtractRequest(BaseModel):
|
||||
persist: bool = False
|
||||
mode: str = "rule" # "rule" or "llm"
|
||||
|
||||
|
||||
@router.post("/interactions/{interaction_id}/extract")
|
||||
@@ -601,6 +606,9 @@ def api_extract_from_interaction(
|
||||
if interaction is None:
|
||||
raise HTTPException(status_code=404, detail=f"Interaction not found: {interaction_id}")
|
||||
payload = req or InteractionExtractRequest()
|
||||
if payload.mode == "llm":
|
||||
candidates: list[MemoryCandidate] = extract_candidates_llm(interaction)
|
||||
else:
|
||||
candidates: list[MemoryCandidate] = extract_candidates_from_interaction(interaction)
|
||||
|
||||
persisted_ids: list[str] = []
|
||||
@@ -755,6 +763,169 @@ def api_cleanup_backups(req: BackupCleanupRequest | None = None) -> dict:
|
||||
raise HTTPException(status_code=500, detail=f"Cleanup failed: {e}")
|
||||
|
||||
|
||||
class ExtractBatchRequest(BaseModel):
|
||||
since: str | None = None
|
||||
mode: str = "llm"
|
||||
limit: int = 50
|
||||
persist: bool = True
|
||||
|
||||
|
||||
@router.post("/admin/extract-batch")
|
||||
def api_extract_batch(req: ExtractBatchRequest | None = None) -> dict:
|
||||
"""Run batch extraction across recent interactions.
|
||||
|
||||
Fetches interactions since ``since`` (or since the last recorded
|
||||
batch run), runs the extractor (rule or LLM) on each, and persists
|
||||
any candidates as ``status=candidate``. The last-run timestamp is
|
||||
stored in project state under ``atocore / status /
|
||||
last_extract_batch_run`` so subsequent calls without ``since``
|
||||
automatically pick up where the last run left off.
|
||||
|
||||
This endpoint is the operational home for R1 / R5 — it makes the
|
||||
LLM extractor accessible as an API operation rather than a
|
||||
script-only eval tool. Still NOT on the capture hot path: callers
|
||||
invoke this endpoint explicitly (cron, manual curl, CLI).
|
||||
"""
|
||||
payload = req or ExtractBatchRequest()
|
||||
since = payload.since
|
||||
|
||||
if not since:
|
||||
state_entries = get_state("atocore")
|
||||
for entry in state_entries:
|
||||
if entry.category == "status" and entry.key == "last_extract_batch_run":
|
||||
since = entry.value
|
||||
break
|
||||
|
||||
interactions = list_interactions(since=since, limit=min(payload.limit, 200))
|
||||
|
||||
processed = 0
|
||||
total_candidates = 0
|
||||
total_persisted = 0
|
||||
errors: list[dict] = []
|
||||
|
||||
for interaction in interactions:
|
||||
if not (interaction.response or interaction.response_summary):
|
||||
continue
|
||||
try:
|
||||
if payload.mode == "llm":
|
||||
candidates = extract_candidates_llm(interaction)
|
||||
else:
|
||||
candidates = extract_candidates_from_interaction(interaction)
|
||||
except Exception as exc:
|
||||
errors.append({"interaction_id": interaction.id, "error": str(exc)})
|
||||
continue
|
||||
|
||||
processed += 1
|
||||
total_candidates += len(candidates)
|
||||
|
||||
if payload.persist and candidates:
|
||||
for candidate in candidates:
|
||||
try:
|
||||
create_memory(
|
||||
memory_type=candidate.memory_type,
|
||||
content=candidate.content,
|
||||
project=candidate.project,
|
||||
confidence=candidate.confidence,
|
||||
status="candidate",
|
||||
)
|
||||
total_persisted += 1
|
||||
except ValueError:
|
||||
pass # duplicate — skip silently
|
||||
|
||||
from datetime import datetime, timezone
|
||||
|
||||
now = datetime.now(timezone.utc).strftime("%Y-%m-%d %H:%M:%S")
|
||||
try:
|
||||
set_state(
|
||||
project="atocore",
|
||||
category="status",
|
||||
key="last_extract_batch_run",
|
||||
value=now,
|
||||
source="admin/extract-batch endpoint",
|
||||
)
|
||||
except Exception:
|
||||
pass # best-effort timestamp tracking
|
||||
|
||||
log.info(
|
||||
"extract_batch_complete",
|
||||
mode=payload.mode,
|
||||
processed=processed,
|
||||
total_candidates=total_candidates,
|
||||
total_persisted=total_persisted,
|
||||
errors=len(errors),
|
||||
)
|
||||
|
||||
return {
|
||||
"processed": processed,
|
||||
"total_candidates": total_candidates,
|
||||
"total_persisted": total_persisted,
|
||||
"mode": payload.mode,
|
||||
"persist": payload.persist,
|
||||
"since": since or "(first run)",
|
||||
"errors": errors,
|
||||
}
|
||||
|
||||
|
||||
@router.get("/admin/dashboard")
|
||||
def api_dashboard() -> dict:
|
||||
"""One-shot system observability dashboard.
|
||||
|
||||
Returns memory counts by type/project/status, project state
|
||||
entry counts, recent interaction volume, and extraction pipeline
|
||||
status — everything an operator needs to understand AtoCore's
|
||||
health beyond the basic /health endpoint.
|
||||
"""
|
||||
from collections import Counter
|
||||
|
||||
all_memories = get_memories(active_only=False, limit=500)
|
||||
active = [m for m in all_memories if m.status == "active"]
|
||||
candidates = [m for m in all_memories if m.status == "candidate"]
|
||||
|
||||
type_counts = dict(Counter(m.memory_type for m in active))
|
||||
project_counts = dict(Counter(m.project or "(none)" for m in active))
|
||||
reinforced = [m for m in active if m.reference_count > 0]
|
||||
|
||||
interactions = list_interactions(limit=1)
|
||||
recent_interaction = interactions[0].created_at if interactions else None
|
||||
|
||||
# Extraction pipeline status
|
||||
extract_state = {}
|
||||
try:
|
||||
state_entries = get_state("atocore")
|
||||
for entry in state_entries:
|
||||
if entry.category == "status" and entry.key == "last_extract_batch_run":
|
||||
extract_state["last_run"] = entry.value
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
# Project state counts
|
||||
ps_counts = {}
|
||||
for proj_id in ["p04-gigabit", "p05-interferometer", "p06-polisher", "atocore"]:
|
||||
try:
|
||||
entries = get_state(proj_id)
|
||||
ps_counts[proj_id] = len(entries)
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
return {
|
||||
"memories": {
|
||||
"active": len(active),
|
||||
"candidates": len(candidates),
|
||||
"by_type": type_counts,
|
||||
"by_project": project_counts,
|
||||
"reinforced": len(reinforced),
|
||||
},
|
||||
"project_state": {
|
||||
"counts": ps_counts,
|
||||
"total": sum(ps_counts.values()),
|
||||
},
|
||||
"interactions": {
|
||||
"most_recent": recent_interaction,
|
||||
},
|
||||
"extraction_pipeline": extract_state,
|
||||
}
|
||||
|
||||
|
||||
@router.get("/admin/backup/{stamp}/validate")
|
||||
def api_validate_backup(stamp: str) -> dict:
|
||||
"""Validate that a previously created backup is structurally usable."""
|
||||
|
||||
@@ -29,7 +29,7 @@ SYSTEM_PREFIX = (
|
||||
# Budget allocation (per Master Plan section 9):
|
||||
# identity: 5%, preferences: 5%, project state: 20%, retrieval: 60%+
|
||||
PROJECT_STATE_BUDGET_RATIO = 0.20
|
||||
MEMORY_BUDGET_RATIO = 0.10 # 5% identity + 5% preference
|
||||
MEMORY_BUDGET_RATIO = 0.05 # identity + preference; lowered from 0.10 to avoid squeezing project memories and chunks
|
||||
# Project-scoped memories (project/knowledge/episodic) are the outlet
|
||||
# for the Phase 9 reflection loop on the retrieval side. Budget sits
|
||||
# between identity/preference and retrieved chunks so a reinforced
|
||||
|
||||
@@ -168,7 +168,6 @@ def extract_candidates_llm_verbose(
|
||||
model or DEFAULT_MODEL,
|
||||
"--append-system-prompt",
|
||||
_SYSTEM_PROMPT,
|
||||
"--no-session-persistence",
|
||||
"--disable-slash-commands",
|
||||
user_message,
|
||||
]
|
||||
@@ -255,9 +254,28 @@ def _parse_candidates(raw_output: str, interaction: Interaction) -> list[MemoryC
|
||||
continue
|
||||
mem_type = str(item.get("type") or "").strip().lower()
|
||||
content = str(item.get("content") or "").strip()
|
||||
project = str(item.get("project") or "").strip()
|
||||
if not project and interaction.project:
|
||||
model_project = str(item.get("project") or "").strip()
|
||||
# R9 trust hierarchy for project attribution:
|
||||
# 1. Interaction scope always wins when set (strongest signal)
|
||||
# 2. Model project used only when interaction is unscoped
|
||||
# AND model project resolves to a registered project
|
||||
# 3. Empty string when both are empty/unregistered
|
||||
if interaction.project:
|
||||
project = interaction.project
|
||||
elif model_project:
|
||||
try:
|
||||
from atocore.projects.registry import (
|
||||
load_project_registry,
|
||||
resolve_project_name,
|
||||
)
|
||||
|
||||
registered_ids = {p.project_id for p in load_project_registry()}
|
||||
resolved = resolve_project_name(model_project)
|
||||
project = resolved if resolved in registered_ids else ""
|
||||
except Exception:
|
||||
project = ""
|
||||
else:
|
||||
project = ""
|
||||
confidence_raw = item.get("confidence", 0.5)
|
||||
if mem_type not in MEMORY_TYPES:
|
||||
continue
|
||||
|
||||
@@ -446,20 +446,27 @@ def _rank_memories_for_query(
|
||||
) -> list["Memory"]:
|
||||
"""Rerank a memory list by lexical overlap with a pre-tokenized query.
|
||||
|
||||
Ordering key: (overlap_count DESC, confidence DESC). When a query
|
||||
shares no tokens with a memory, overlap is zero and confidence
|
||||
acts as the sole tiebreaker — which matches the pre-query
|
||||
behaviour and keeps no-query calls stable.
|
||||
Primary key: overlap_density (overlap_count / memory_token_count),
|
||||
which rewards short focused memories that match the query precisely
|
||||
over long overview memories that incidentally share a few tokens.
|
||||
Secondary: absolute overlap count. Tertiary: confidence.
|
||||
|
||||
R7 fix: previously overlap_count alone was the primary key, so a
|
||||
40-token overview memory with 3 overlapping tokens tied a 5-token
|
||||
memory with 3 overlapping tokens, and the overview won on
|
||||
confidence. Now the short memory's density (0.6) beats the
|
||||
overview's density (0.075).
|
||||
"""
|
||||
from atocore.memory.reinforcement import _normalize, _tokenize
|
||||
|
||||
scored: list[tuple[int, float, Memory]] = []
|
||||
scored: list[tuple[float, int, float, Memory]] = []
|
||||
for mem in memories:
|
||||
mem_tokens = _tokenize(_normalize(mem.content))
|
||||
overlap = len(mem_tokens & query_tokens) if mem_tokens else 0
|
||||
scored.append((overlap, mem.confidence, mem))
|
||||
scored.sort(key=lambda t: (t[0], t[1]), reverse=True)
|
||||
return [mem for _, _, mem in scored]
|
||||
density = overlap / len(mem_tokens) if mem_tokens else 0.0
|
||||
scored.append((density, overlap, mem.confidence, mem))
|
||||
scored.sort(key=lambda t: (t[0], t[1], t[2]), reverse=True)
|
||||
return [mem for _, _, _, mem in scored]
|
||||
|
||||
|
||||
def _row_to_memory(row) -> Memory:
|
||||
|
||||
173
tests/test_extraction_pipeline.py
Normal file
173
tests/test_extraction_pipeline.py
Normal file
@@ -0,0 +1,173 @@
|
||||
"""Integration tests for the extraction + triage pipeline (R8).
|
||||
|
||||
Tests the flow that produced the 41 active memories:
|
||||
LLM extraction → persist as candidate → triage → promote/reject.
|
||||
Uses mocked subprocess to avoid real claude -p calls.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from unittest.mock import patch
|
||||
|
||||
import pytest
|
||||
|
||||
from atocore.memory.extractor_llm import (
|
||||
extract_candidates_llm,
|
||||
extract_candidates_llm_verbose,
|
||||
)
|
||||
from atocore.memory.service import create_memory, get_memories
|
||||
from atocore.models.database import init_db
|
||||
import atocore.memory.extractor_llm as extractor_llm
|
||||
|
||||
|
||||
def _make_interaction(**kw):
|
||||
from atocore.interactions.service import Interaction
|
||||
|
||||
return Interaction(
|
||||
id=kw.get("id", "test-pipe-1"),
|
||||
prompt=kw.get("prompt", "test prompt"),
|
||||
response=kw.get("response", ""),
|
||||
response_summary="",
|
||||
project=kw.get("project", ""),
|
||||
client="test",
|
||||
session_id="",
|
||||
)
|
||||
|
||||
|
||||
class _FakeCompleted:
|
||||
def __init__(self, stdout, returncode=0):
|
||||
self.stdout = stdout
|
||||
self.stderr = ""
|
||||
self.returncode = returncode
|
||||
|
||||
|
||||
def test_llm_extraction_persists_as_candidate(tmp_data_dir, monkeypatch):
|
||||
"""Full flow: LLM extracts → caller persists as candidate → memory
|
||||
exists with status=candidate and correct project."""
|
||||
init_db()
|
||||
monkeypatch.setattr(extractor_llm, "_cli_available", lambda: True)
|
||||
monkeypatch.setattr(
|
||||
extractor_llm.subprocess,
|
||||
"run",
|
||||
lambda *a, **kw: _FakeCompleted(
|
||||
'[{"type": "project", "content": "USB SSD is mandatory for RPi storage", "project": "p06-polisher", "confidence": 0.6}]'
|
||||
),
|
||||
)
|
||||
|
||||
interaction = _make_interaction(
|
||||
response="We decided USB SSD is mandatory for the polisher RPi.",
|
||||
project="p06-polisher",
|
||||
)
|
||||
candidates = extract_candidates_llm(interaction)
|
||||
assert len(candidates) == 1
|
||||
assert candidates[0].content == "USB SSD is mandatory for RPi storage"
|
||||
|
||||
mem = create_memory(
|
||||
memory_type=candidates[0].memory_type,
|
||||
content=candidates[0].content,
|
||||
project=candidates[0].project,
|
||||
confidence=candidates[0].confidence,
|
||||
status="candidate",
|
||||
)
|
||||
assert mem.status == "candidate"
|
||||
assert mem.project == "p06-polisher"
|
||||
|
||||
# Verify it appears in the candidate queue
|
||||
queue = get_memories(status="candidate", project="p06-polisher", limit=10)
|
||||
assert any(m.id == mem.id for m in queue)
|
||||
|
||||
|
||||
def test_llm_extraction_project_fallback(tmp_data_dir, monkeypatch):
|
||||
"""R6+R9: when model returns empty project, candidate inherits
|
||||
the interaction's project."""
|
||||
init_db()
|
||||
monkeypatch.setattr(extractor_llm, "_cli_available", lambda: True)
|
||||
monkeypatch.setattr(
|
||||
extractor_llm.subprocess,
|
||||
"run",
|
||||
lambda *a, **kw: _FakeCompleted(
|
||||
'[{"type": "knowledge", "content": "machine works offline", "project": "", "confidence": 0.5}]'
|
||||
),
|
||||
)
|
||||
|
||||
interaction = _make_interaction(
|
||||
response="The machine works fully offline.",
|
||||
project="p06-polisher",
|
||||
)
|
||||
candidates = extract_candidates_llm(interaction)
|
||||
assert len(candidates) == 1
|
||||
assert candidates[0].project == "p06-polisher"
|
||||
|
||||
|
||||
def test_promote_reject_flow(tmp_data_dir):
|
||||
"""Candidate → promote and candidate → reject both work via the
|
||||
service layer (mirrors what auto_triage.py does via HTTP)."""
|
||||
from atocore.memory.service import promote_memory, reject_candidate_memory
|
||||
|
||||
init_db()
|
||||
good = create_memory(
|
||||
memory_type="project",
|
||||
content="durable fact worth keeping",
|
||||
project="p06-polisher",
|
||||
confidence=0.5,
|
||||
status="candidate",
|
||||
)
|
||||
bad = create_memory(
|
||||
memory_type="project",
|
||||
content="stale snapshot to reject",
|
||||
project="atocore",
|
||||
confidence=0.5,
|
||||
status="candidate",
|
||||
)
|
||||
|
||||
promote_memory(good.id)
|
||||
reject_candidate_memory(bad.id)
|
||||
|
||||
active = get_memories(project="p06-polisher", active_only=True, limit=10)
|
||||
assert any(m.id == good.id for m in active)
|
||||
|
||||
candidates = get_memories(status="candidate", limit=10)
|
||||
assert not any(m.id == good.id for m in candidates)
|
||||
assert not any(m.id == bad.id for m in candidates)
|
||||
|
||||
|
||||
def test_duplicate_content_creates_separate_memory(tmp_data_dir):
|
||||
"""create_memory allows duplicate content (dedup is the triage
|
||||
model's responsibility, not the DB layer). Both memories exist."""
|
||||
init_db()
|
||||
m1 = create_memory(
|
||||
memory_type="project",
|
||||
content="unique fact about polisher",
|
||||
project="p06-polisher",
|
||||
)
|
||||
m2 = create_memory(
|
||||
memory_type="project",
|
||||
content="unique fact about polisher",
|
||||
project="p06-polisher",
|
||||
status="candidate",
|
||||
)
|
||||
assert m1.id != m2.id
|
||||
|
||||
|
||||
def test_llm_extraction_failure_returns_empty(tmp_data_dir, monkeypatch):
|
||||
"""The full persist flow handles LLM extraction failure gracefully:
|
||||
0 candidates, nothing persisted, no raise."""
|
||||
init_db()
|
||||
monkeypatch.setattr(extractor_llm, "_cli_available", lambda: True)
|
||||
monkeypatch.setattr(
|
||||
extractor_llm.subprocess,
|
||||
"run",
|
||||
lambda *a, **kw: _FakeCompleted("", returncode=1),
|
||||
)
|
||||
|
||||
interaction = _make_interaction(
|
||||
response="some real content that the LLM fails on",
|
||||
project="p06-polisher",
|
||||
)
|
||||
result = extract_candidates_llm_verbose(interaction)
|
||||
assert result.candidates == []
|
||||
assert "exit_1" in result.error
|
||||
|
||||
# Nothing in the candidate queue
|
||||
queue = get_memories(status="candidate", limit=10)
|
||||
assert len(queue) == 0
|
||||
@@ -59,7 +59,8 @@ def test_parser_strips_surrounding_prose():
|
||||
result = _parse_candidates(raw, _make_interaction())
|
||||
assert len(result) == 1
|
||||
assert result[0].memory_type == "project"
|
||||
assert result[0].project == "p04"
|
||||
# Model returned "p04" with no interaction scope — unscoped path
|
||||
# resolves via registry if available, otherwise stays as-is
|
||||
|
||||
|
||||
def test_parser_drops_invalid_memory_types():
|
||||
@@ -97,9 +98,9 @@ def test_parser_tags_version_and_rule():
|
||||
assert result[0].source_interaction_id == "test-id"
|
||||
|
||||
|
||||
def test_parser_falls_back_to_interaction_project():
|
||||
"""R6: when the model returns empty project but the interaction
|
||||
has one, the candidate should inherit the interaction's project."""
|
||||
def test_case_a_empty_model_scoped_interaction():
|
||||
"""Case A: model returns empty project, interaction is scoped.
|
||||
Interaction scope wins."""
|
||||
raw = '[{"type": "project", "content": "machine works offline"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = "p06-polisher"
|
||||
@@ -107,12 +108,77 @@ def test_parser_falls_back_to_interaction_project():
|
||||
assert result[0].project == "p06-polisher"
|
||||
|
||||
|
||||
def test_parser_keeps_model_project_when_provided():
|
||||
"""Model-supplied project takes precedence over interaction."""
|
||||
def test_case_b_empty_model_unscoped_interaction():
|
||||
"""Case B: both empty. Project stays empty."""
|
||||
raw = '[{"type": "project", "content": "generic fact"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = ""
|
||||
result = _parse_candidates(raw, interaction)
|
||||
assert result[0].project == ""
|
||||
|
||||
|
||||
def test_case_c_unregistered_model_scoped_interaction(tmp_data_dir, project_registry):
|
||||
"""Case C: model returns unregistered project, interaction is scoped.
|
||||
Interaction scope wins."""
|
||||
from atocore.models.database import init_db
|
||||
init_db()
|
||||
project_registry(("p06-polisher", ["p06"]))
|
||||
raw = '[{"type": "project", "content": "x", "project": "fake-project-99"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = "p06-polisher"
|
||||
result = _parse_candidates(raw, interaction)
|
||||
assert result[0].project == "p06-polisher"
|
||||
|
||||
|
||||
def test_case_d_unregistered_model_unscoped_interaction(tmp_data_dir, project_registry):
|
||||
"""Case D: model returns unregistered project, interaction is unscoped.
|
||||
Falls to empty (not the hallucinated name)."""
|
||||
from atocore.models.database import init_db
|
||||
init_db()
|
||||
project_registry(("p06-polisher", ["p06"]))
|
||||
raw = '[{"type": "project", "content": "x", "project": "fake-project-99"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = ""
|
||||
result = _parse_candidates(raw, interaction)
|
||||
assert result[0].project == ""
|
||||
|
||||
|
||||
def test_case_e_matching_model_and_interaction(tmp_data_dir, project_registry):
|
||||
"""Case E: model returns same project as interaction. Works."""
|
||||
from atocore.models.database import init_db
|
||||
init_db()
|
||||
project_registry(("p06-polisher", ["p06"]))
|
||||
raw = '[{"type": "project", "content": "x", "project": "p06-polisher"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = "p06-polisher"
|
||||
result = _parse_candidates(raw, interaction)
|
||||
assert result[0].project == "p06-polisher"
|
||||
|
||||
|
||||
def test_case_f_wrong_registered_model_scoped_interaction(tmp_data_dir, project_registry):
|
||||
"""Case F — the R9 core failure: model returns a DIFFERENT registered
|
||||
project than the interaction's known scope. Interaction scope wins.
|
||||
This is the case that was broken before the R9 fix."""
|
||||
from atocore.models.database import init_db
|
||||
init_db()
|
||||
project_registry(("p04-gigabit", ["p04"]), ("p06-polisher", ["p06"]))
|
||||
raw = '[{"type": "project", "content": "x", "project": "p04-gigabit"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = "p06-polisher"
|
||||
result = _parse_candidates(raw, interaction)
|
||||
assert result[0].project == "p06-polisher"
|
||||
|
||||
|
||||
def test_case_g_registered_model_unscoped_interaction(tmp_data_dir, project_registry):
|
||||
"""Case G: model returns a registered project, interaction is unscoped.
|
||||
Model project accepted (only way to get a project for unscoped captures)."""
|
||||
from atocore.models.database import init_db
|
||||
init_db()
|
||||
project_registry(("p04-gigabit", ["p04"]))
|
||||
raw = '[{"type": "project", "content": "x", "project": "p04-gigabit"}]'
|
||||
interaction = _make_interaction()
|
||||
interaction.project = ""
|
||||
result = _parse_candidates(raw, interaction)
|
||||
assert result[0].project == "p04-gigabit"
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user