tomtan/memory-gateway
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

neutralize upstream service branding

Browse Source
This commit is contained in:
tomtan
2026-06-12 16:31:08 +08:00
parent 126ae4eafa
commit 42de7f9da0
18 changed files with 340 additions and 256 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
skill/memory-gateway-agent/SKILL.md
View File

@ -23,7 +23,7 @@ Do not write a real `user_key` into source files, prompts, logs, or committed do
## Workflow
1. Run `$CLI health` when connectivity or EverOS availability is uncertain.
1. Run `$CLI health` when connectivity or upstream memory service availability is uncertain.
2. Use an existing `user_id` and `user_key`. Run `create-user` only when the user explicitly needs a new Gateway identity.
3. Choose the operation:
- Upload durable user files with `upload-resource`.
@ -58,7 +58,7 @@ Read [references/api.md](references/api.md) when choosing scopes, constructing m
- Do not expose internal file paths. Return the Gateway's `resource://{user_id}/{resource_id}` URI to users.
- Do not claim ingestion succeeded unless the upload status is `extracted` or flush reports success.
- Treat `health.status = degraded` as Gateway available but EverOS unavailable.
- Resource deletion is soft deletion in Gateway search scope and removes the Gateway upload copy; it does not delete EverOS internal indexes.
- Treat `health.status = degraded` as Gateway available but upstream memory service unavailable.
- Resource deletion is soft deletion in Gateway search scope and removes the Gateway upload copy; it does not delete upstream memory service internal indexes.
- Memory override and deletion require an owned `resource:{user_id}:{resource_id}` or `memory_edit:{user_id}` session.
- Ask for confirmation before destructive deletion unless the user's current request explicitly instructs deletion.