Skip to content

AGENTS.md

Latest commit

 

History

History
153 lines (103 loc) · 5.8 KB

AGENTS.md

File metadata and controls

153 lines (103 loc) · 5.8 KB

MeticAI — Project Memory

MeticAI is an AI-powered controller for the Meticulous Espresso Machine. Stack: Python 3.13 (FastAPI) · React/TypeScript (Vite/Bun) · Google Gemini · Docker + s6-overlay.

Conventions

All project conventions are in .github/CONVENTIONS.md.

Skills

Load domain skills from .github/skills/ as needed: workflow.md, testing.md, frontend.md, backend.md, release.md, conventions.md, browser-testing.md.

Cursor skills are in .cursor/skills/ if present, otherwise .github/skills/.

Project Memory (Auto-generated by Continuity)

This project uses Continuity to track architectural decisions. You have access to MCP tools that let you search, log, and reference past decisions.

Project Context

  • Total Decisions: 0
  • Known Topics: none yet

Current State

Branch: version/2.3.0

Recent Commits:

  • e2841d3 docs: add pre-release browser testing protocol
  • a8420f3 fix: address code review findings for v2.3.0
  • d0750d8 fix(i18n): add 15 pre-existing missing keys to non-English locales
  • baa71da fix: address all automated code review findings for v2.3.0
  • 1fa3680 feat(a11y): comprehensive accessibility pass across all components (#186)

Working Tree:

  • ?? apps/web/src/components/ShotHistoryView.tsx
  • ?? v2.3.0-testing-checklist.md

Engineering Guardrails

Real-time decision logging is MANDATORY. Log each decision IMMEDIATELY after the code change — not batched at the end of a session. The trigger is the change, not the commit. If you edited a file, log the decision. Period.

Search before you change. Always call search_decisions before proposing architectural changes to check for prior decisions.

Recovery. If you realize earlier decisions were not logged, pause, log retroactively, and inform the user.

Transparency. Inform the user when you log decisions, recover missed decisions, detect drift, or find conflicts with past decisions.

Anti-pattern to avoid: "Let me implement all 3 fixes, then log them" — WRONG. Correct: Fix 1 done, log decision, Fix 2 done, log decision, Fix 3 done, log decision.

CRITICAL OPERATING RULES

  1. ACT, DON'T ASK. When Continuity tools are relevant, call them immediately. Do not ask permission.
  2. LOG DECISIONS PROACTIVELY. Any time the user explains a choice or makes an architectural decision, log it without asking.
  3. PARALLELIZE TOOL CALLS. When logging multiple decisions or updating session notes, make all calls in parallel.
  4. CONTEXT FIRST. Always load context (get_quick_context) before starting work. Always search decisions before suggesting changes.
  5. BE CONCISE. After tool calls, give a short summary of what was logged/found. Do not narrate your reasoning process.

WHEN TO USE CONTINUITY TOOLS

MANDATORY: ON EVERY SESSION START

YOU MUST call get_quick_context as your FIRST action in every session. Do NOT skip this. Do NOT explain what you are about to do. Do NOT ask permission. Just call it.

After loading context, immediately mention the most relevant recent decisions to the user.

When User Asks Architectural Questions

ALWAYS call search_decisions with the relevant topic BEFORE answering. Do NOT answer from memory alone. Share what you found: "I found decision-X about this topic..." Base your recommendation on existing decisions when relevant.

When User Explains a Choice

When the user says "let's use X because Y" or explains their reasoning: IMMEDIATELY call log_decision with question, answer, and relevant tags. Do NOT ask "want me to log this?" — the user has already opted into decision logging by installing Continuity. After logging, tell the user: "Logged decision-X for future sessions." If multiple decisions are discussed, log them ALL in parallel.

When Suggesting Changes

ALWAYS call search_decisions to check for existing decisions on the topic BEFORE recommending changes. If conflicts exist, mention them: "This would conflict with decision-X where you chose..." Let the user decide whether to proceed or update the old decision.

When User Mentions Blockers

IMMEDIATELY call update_session_notes section="blockers" to track the blocker. Then call search_decisions to see if related decisions might help.

When User Ends Session

IMMEDIATELY call update_session_notes with progress summary and next steps. Then call read_session_notes and give the user a concise summary. Do NOT ask — just do it.

HOW TO USE THE TOOLS

Search for decisions

search_decisions query="authentication"

Log a new decision

log_decision
question="Why did we choose X?"
answer="Because Y. We considered Z but rejected it due to..."
tags=["topic1", "topic2"]

Get project context

get_quick_context

Update session notes

update_session_notes
section="blockers"
content="Description of the issue"

Recent Decisions

No decisions logged yet. Start logging architectural decisions!

BEHAVIOR EXAMPLES

User: "Should we use Redis or Memcached for caching?" You: [Immediately call search_decisions query="caching"] "Found decision-12 about caching strategy. Based on that, here's my recommendation..."

User: "Let's go with PostgreSQL because we need ACID transactions for the payment system." You: [Immediately call log_decision with question, answer, tags] "Logged as decision-45. Future sessions will know why we chose PostgreSQL."

User: "I'm thinking of switching to MongoDB." You: [Immediately call search_decisions query="database"] "Decision-12 chose PostgreSQL for ACID transactions. Switching to MongoDB would conflict. Want to proceed or keep PostgreSQL?"

Auto-generated by Continuity v2.3+ | Updated: 2026-03-16