Skip to content

memory remember/save CLI: enforce basename length cap at write time, not just downstream #28

Description

@MohabMohie

Background

We use @aictx/memory (currently 0.1.55) in ShaftHQ/SHAFT_ENGINE to write gotcha/decision memories to .memory/memory/gotchas/*. That repo runs a downstream CI check (validate_agent_setup.py, check id memory-filename-length) that rejects basenames over 160 chars (Windows MAX_PATH risk).

That downstream check has caught an overlong basename five separate times across unrelated PRs: ShaftHQ/SHAFT_ENGINE#3817, #3991, #4110, #4247, #4304. Each time it was fixed reactively, after the fact, in whatever PR happened to trip CI — never at the moment the memory was actually created, when the author had full context to pick a good short id.

Root cause

memory remember / memory save derives the gotcha filename/id from the memory's title/content at creation time and does not validate or cap that derived basename length. Any session that writes a gotcha with a long auto-derived id silently creates a file that will eventually fail some unrelated downstream consumer's length check.

Suggested fix

Validate the derived basename length inside the CLI itself at write time: either truncate deterministically to fit a configurable cap (e.g. 160 chars), or reject with an actionable error such as "id too long (N chars), pass an explicit shorter --id".

Full context/discussion: ShaftHQ/SHAFT_ENGINE#4306 (opened there first, redirected here after confirming the CLI itself — not the consumer repo — owns this behavior).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions