Decision Tracking

Use memory_store:
- title: "StrEnum over Postgres ENUM for choice fields"
- memory_type: "decision"
- content: "We use Python StrEnum instead of Postgres ENUM for all choice fields (memory_type, relationship_type, job_status, etc). Postgres ENUMs require DDL migrations to add new values — ALTER TYPE cannot run inside a transaction, which makes zero-downtime deploys harder. StrEnum values are stored as VARCHAR, migrations for new values are just data migrations, and we can add new values without touching the schema. Trade-off: no DB-level constraint on valid values, but application-level validation via Pydantic covers this. Decision made during D7 migration planning."
- concepts: ["database schema", "ENUM", "migrations", "StrEnum", "PostgreSQL"]
- files: ["api/neuroloom_api/models/"]
- importance: 0.92
- tags: ["schema", "migrations", "adr"]

curl -X POST https://api.neuroloom.dev/api/v1/memories/store \
  -H "Authorization: Token $MEMORIES_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$MEMORIES_WORKSPACE_ID"'",
    "title": "StrEnum over Postgres ENUM for choice fields",
    "memory_type": "decision",
    "narrative": "We use Python StrEnum instead of Postgres ENUM for all choice fields. Postgres ENUMs require DDL migrations to add new values — ALTER TYPE cannot run inside a transaction, which makes zero-downtime deploys harder. StrEnum values are stored as VARCHAR, migrations for new values are just data migrations, and we can add new values without touching the schema. Trade-off: no DB-level constraint on valid values, but application-level validation via Pydantic covers this.",
    "concepts": ["database schema", "ENUM", "migrations", "StrEnum", "PostgreSQL"],
    "source_files": ["api/neuroloom_api/models/"],
    "importance_score": 0.92,
    "tags": ["schema", "migrations", "adr"]
  }'

import os
import httpx

token = os.environ["MEMORIES_API_TOKEN"]
workspace_id = os.environ["MEMORIES_WORKSPACE_ID"]

response = httpx.post(
    "https://api.neuroloom.dev/api/v1/memories/store",
    headers={"Authorization": f"Token {token}"},
    json={
        "workspace_id": workspace_id,
        "title": "StrEnum over Postgres ENUM for choice fields",
        "memory_type": "decision",
        "narrative": (
            "We use Python StrEnum instead of Postgres ENUM for all choice fields. "
            "Postgres ENUMs require DDL migrations to add new values — ALTER TYPE "
            "cannot run inside a transaction, which makes zero-downtime deploys harder. "
            "StrEnum values are stored as VARCHAR, migrations for new values are just "
            "data migrations, and we can add new values without touching the schema."
        ),
        "concepts": ["database schema", "ENUM", "migrations", "StrEnum", "PostgreSQL"],
        "source_files": ["api/neuroloom_api/models/"],
        "importance_score": 0.92,
        "tags": ["schema", "migrations", "adr"],
    },
)
memory = response.json()
print(f"Stored: {memory['id']} — {memory['title']}")

Use memory_store:
- title: "Zero-downtime migration strategy"
- memory_type: "decision"
- content: "All schema migrations must be backward-compatible for at least one deploy cycle. We use the expand-contract pattern: first migration adds the new column or table, application code is deployed to write to both old and new, second migration removes the old column. This allows rollback without data loss. Postgres DDL inside transactions is the key constraint that shapes this approach."
- concepts: ["migrations", "zero-downtime", "expand-contract", "PostgreSQL", "Alembic"]
- files: ["api/alembic/", "api/neuroloom_api/"]
- importance: 0.90
- tags: ["migrations", "adr", "deployment"]

Use memory_explore with query "migration strategy" to find the related memory IDs, then store a relationship linking "StrEnum over Postgres ENUM" (mem-2e7b9f3d) to the zero-downtime migration memory with relationship_type "related_to"

# Store the related decision
RELATED_ID=$(curl -s -X POST https://api.neuroloom.dev/api/v1/memories/store \
  -H "Authorization: Token $MEMORIES_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$MEMORIES_WORKSPACE_ID"'",
    "title": "Zero-downtime migration strategy",
    "memory_type": "decision",
    "narrative": "All schema migrations must be backward-compatible for at least one deploy cycle. We use the expand-contract pattern: first migration adds the new column, application writes to both, second migration removes the old column.",
    "concepts": ["migrations", "zero-downtime", "expand-contract", "PostgreSQL", "Alembic"],
    "source_files": ["api/alembic/"],
    "importance_score": 0.90,
    "tags": ["migrations", "adr", "deployment"]
  }' | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])")

# Create a relationship between the two decisions
curl -X POST https://api.neuroloom.dev/api/v1/memories/relationships \
  -H "Authorization: Token $MEMORIES_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$MEMORIES_WORKSPACE_ID"'",
    "source_memory_id": "mem-2e7b9f3d",
    "target_memory_id": "'"$RELATED_ID"'",
    "relationship_type": "related_to",
    "confidence": 0.9
  }'

Use memory_search with query "why do we use this migration approach" and memory_types ["decision"] and tags ["adr"]

curl -X POST https://api.neuroloom.dev/api/v1/memories/search \
  -H "Authorization: Token $MEMORIES_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$MEMORIES_WORKSPACE_ID"'",
    "query": "why do we use this migration approach",
    "memory_types": ["decision"],
    "tags": ["adr"],
    "limit": 10
  }'

response = httpx.post(
    "https://api.neuroloom.dev/api/v1/memories/search",
    headers={"Authorization": f"Token {token}"},
    json={
        "workspace_id": workspace_id,
        "query": "why do we use this migration approach",
        "memory_types": ["decision"],
        "tags": ["adr"],
        "limit": 10,
    },
)
for r in response.json()["results"]:
    print(f"{r['score']:.2f}  [{r['memory_type']}]  {r['title']}")

Use memory_by_file with file_path "api/alembic/"

curl -X POST https://api.neuroloom.dev/api/v1/memories/by-file \
  -H "Authorization: Token $MEMORIES_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$MEMORIES_WORKSPACE_ID"'",
    "file_path": "api/alembic/",
    "limit": 20
  }'

# Store the original (now superseded) decision first if it doesn't exist
OLD_ID="mem-1a2b3c4d"  # ID of the original ENUM decision

# Create a SUPERSEDES relationship from the new decision to the old one
curl -X POST https://api.neuroloom.dev/api/v1/memories/relationships \
  -H "Authorization: Token $MEMORIES_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$MEMORIES_WORKSPACE_ID"'",
    "source_memory_id": "mem-2e7b9f3d",
    "target_memory_id": "'"$OLD_ID"'",
    "relationship_type": "supersedes",
    "confidence": 1.0
  }'

# Link new decision as superseding the old one
response = httpx.post(
    "https://api.neuroloom.dev/api/v1/memories/relationships",
    headers={"Authorization": f"Token {token}"},
    json={
        "workspace_id": workspace_id,
        "source_memory_id": "mem-2e7b9f3d",   # StrEnum decision (new)
        "target_memory_id": "mem-1a2b3c4d",    # Postgres ENUM decision (old)
        "relationship_type": "supersedes",
        "confidence": 1.0,
    },
)
print(response.json())