Summary
apc memory add creates entries using the old entry_id schema, while apc collect creates entries using the new content-hash id/source_file schema. This causes a mixed-schema cache where apc status shows inflated and confusing memory counts.
Steps to Reproduce
# Add some manual memory entries
apc memory add "prefer Python type hints"
apc memory add "use pytest for testing"
# Run collect
apc collect -y
# Check status
apc status
# Shows: Memory: 197 (or whatever large number)
# But you only added 2 entries manually + collect found 6 files!
Actual Behavior
apc memory add stores entries with schema: {"entry_id": ..., "category": ..., "content": ..., "source": "manual_add"}
apc collect stores entries with schema: {"id": ..., "source_tool": ..., "source_file": ..., "label": ..., "content": ..., "collected_at": ...}
- Both schemas coexist in
~/.apc/cache/memory.json
apc status reports the total count of ALL entries (both schemas combined) as a single "Memory" number — very confusing
In this test environment with 195 manually-added test entries (from Docker integration tests), apc status shows Memory: 203 even though there are only 8 actually-collected memory files. New users running apc memory add followed by apc collect will see memory counts far higher than expected.
Expected Behavior
Option A: Migrate apc memory add to use the new id-based schema for consistency.
Option B: apc status should separately report:
- Collected files: 8 (from
apc collect)
- Manual entries: 195 (from
apc memory add)
Option C: apc memory add should clearly be documented as a legacy command that creates a different type of entry.
Affected Code
# src/memory.py — add() command still uses old schema:
new_entry = {
"entry_id": entry_id, # OLD schema
"category": category,
"content": text,
"source": "manual_add",
}
Environment
- macOS Darwin 25.2.0 (arm64)
- apc version 0.1.0
Severity
Medium — Creates user confusion about memory count and makes it hard to audit what's actually being synced to AI tools.
Summary
apc memory addcreates entries using the oldentry_idschema, whileapc collectcreates entries using the new content-hashid/source_fileschema. This causes a mixed-schema cache whereapc statusshows inflated and confusing memory counts.Steps to Reproduce
Actual Behavior
apc memory addstores entries with schema:{"entry_id": ..., "category": ..., "content": ..., "source": "manual_add"}apc collectstores entries with schema:{"id": ..., "source_tool": ..., "source_file": ..., "label": ..., "content": ..., "collected_at": ...}~/.apc/cache/memory.jsonapc statusreports the total count of ALL entries (both schemas combined) as a single "Memory" number — very confusingIn this test environment with 195 manually-added test entries (from Docker integration tests),
apc statusshows Memory: 203 even though there are only 8 actually-collected memory files. New users runningapc memory addfollowed byapc collectwill see memory counts far higher than expected.Expected Behavior
Option A: Migrate
apc memory addto use the newid-based schema for consistency.Option B:
apc statusshould separately report:apc collect)apc memory add)Option C:
apc memory addshould clearly be documented as a legacy command that creates a different type of entry.Affected Code
Environment
Severity
Medium — Creates user confusion about memory count and makes it hard to audit what's actually being synced to AI tools.