Hein
56c84df342
- Add OAuth 2.0 support with authorization code flow and dynamic client registration. - Introduce new handlers for OAuth metadata, client registration, authorization, and token issuance. - Enhance authentication middleware to support OAuth client credentials. - Create in-memory stores for authorization codes and tokens. - Update configuration to include OAuth client details. - Ensure validation checks for OAuth clients in the configuration.
44 lines
2.5 KiB
Markdown
44 lines
2.5 KiB
Markdown
# AMCS Memory Instructions
|
|
|
|
AMCS (Avalon Memory Crystal Server) is an MCP server for capturing and retrieving thoughts, memory, and project context. It is backed by Postgres with pgvector for semantic search.
|
|
|
|
You have access to an MCP memory server named AMCS.
|
|
|
|
Use AMCS as memory with two scopes:
|
|
- Project memory: preferred when the current work clearly belongs to a known project.
|
|
- Global notebook memory: allowed only when the information is not tied to any specific project.
|
|
|
|
## Scope Selection Rules
|
|
|
|
1. Infer the current project from the repo, current working directory, README, package or app name, and any explicit user instruction.
|
|
2. Call `get_active_project`.
|
|
3. If the active project clearly matches the current work, use it.
|
|
4. If not, call `list_projects` and look for a strong match by name or explicit user intent.
|
|
5. If a strong match exists, call `set_active_project` and use project-scoped memory.
|
|
6. If no strong project match exists, you may use global notebook memory with no project.
|
|
7. If multiple projects plausibly match, ask the user before reading or writing project memory.
|
|
|
|
## Project Memory Rules
|
|
|
|
- Use project memory for code decisions, architecture, TODOs, debugging findings, and context specific to the current repo or workstream.
|
|
- Before substantial work, always retrieve context with `get_project_context` or `recall_context` so prior decisions inform your approach.
|
|
- Save durable project facts with `capture_thought` after completing meaningful work.
|
|
- Do not attach memory to the wrong project.
|
|
|
|
## Global Notebook Rules
|
|
|
|
- Use global memory only for information that is genuinely cross-project or not project-bound.
|
|
- Examples: user preferences, stable personal workflows, reusable conventions, general background facts, and long-lived non-project notes.
|
|
- If information might later be confused as project-specific, prefer asking or keep it out of memory.
|
|
|
|
## Memory Hygiene
|
|
|
|
- Save only durable, useful information.
|
|
- Do not save secrets, raw logs, or transient noise.
|
|
- Prefer concise summaries.
|
|
- When saving, choose the narrowest correct scope: project if project-specific, global if not.
|
|
|
|
## Short Operational Form
|
|
|
|
Use AMCS memory in project scope when the current work matches a known project. If no clear project matches, global notebook memory is allowed for non-project-specific information. Never store project-specific memory globally when a matching project exists, and never store memory in the wrong project. If project matching is ambiguous, ask the user.
|