dodil/erp-brick-activity

AGENTS.md

Instructions for agents working on brick-activity

This brick is built on erp-platform. Read its BRICKS.md before changing anything here — it holds the rules (ownership, use cases, data, identity, tests) and why each one exists.

Where a change goes

You are changing…It goes in
a rule about contacts, activities or taskssrc/brick_activity/domain/activity.py — and a test in tests/test_rules.py named for the story
who may do somethingsrc/brick_activity/application/use_cases.py — the permission, or _may_change()
a new action for people and agentsa new @ACT.use_case in application/ — it becomes a route AND a tool
a column or tablesrc/brick_activity/schema.sql (append; never drop or rename) and infrastructure/tables.py

Never add an HTTP route or an MCP tool by hand. Never import SQLAlchemy, FastAPI or MCP in domain/.

Before you commit

pytest -q --tb=short        # rules + both doors, no bucket needed

Add a test to tests/test_doors.py for any new use case: the outcome through the API and through MCP, and the 404 for another person's row.

Don't

  • Don't read a deal someone NAMED (a timeline filter, a call logged onto it) as this brick's service identity: ask the pipeline seam with caller=caller, so a deal they may not see is 404 (H5).

  • Don't let the email claim's loser crash: add_contact recognises a lost claim at the INSERT or at COMMIT (lost_email_claim) and answers the winner's contact.

  • Don't save a contact or a task without its loaded version, and don't retry a change whose caller sent one.

  • Don't write to another brick's tables — call its seam (PARTNERS, PIPELINE in use_cases.py).

  • Don't turn the email claim into an upsert: the plain INSERT failing on a duplicate IS the uniqueness.

  • Don't write an upsert or DELETE by hand — use the repository (DataK3's ON CONFLICT differs from Postgres).

  • Don't commit credentials or .env.