Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions aimem/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,8 @@ environment and this skill does not apply.

Read these (co-located with this file, under `references/`) on demand:

- **`references/navigation.md`** — how to identify the bucket/region/endpoint
of your mount, and the conventional layout of files at the root.
- **`references/navigation.md`** — how to locate your mount and the
conventional layout of files at its root.
- **`references/workspace.md`** — POSIX semantics: copy-on-write staging,
close/fsync durability, rename, and what doesn't work.
- **`references/memory.md`** — where to put long-lived agent context
Expand Down
2 changes: 1 addition & 1 deletion aimem/references/annotations.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ object), so annotations can never collide with actual keys.

If a note write fails with an I/O error or "No such file or directory", you
almost certainly used the wrong `<object-path>` (a dropped directory prefix
or a stale name) — you do **not** need to `mkdir` the annotation directory,
or a stale name). You do **not** need to `mkdir` the annotation directory;
it resolves automatically for an object that exists. Re-derive the path from
the object's exact key and retry; do not conclude the annotation channel is
unavailable.
Expand Down
4 changes: 2 additions & 2 deletions aimem/references/memory.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,8 @@
aimem warms a curated set of well-known agent memory files into
its read cache on mount, so that recalling them from a fresh
sandbox is fast. Write your project context to one of these
conventional paths and other agents on this mount will be able to
read it without you having to point at it.
conventional paths. Other agents on this mount can then read it
without you pointing them at it.

The exact set warmed depends on the `--agent` profile the mount was
started with (claude, codex, cursor, or auto — which warms all of
Expand Down
6 changes: 3 additions & 3 deletions aimem/references/metadata.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,11 +49,11 @@ lookup/listing. The filesystem does not reject a
`setfattr -n user.s3.meta.foo -v bar path` — but it does **not** update
the object's native S3 user metadata or create an S3 tag either. The
value is instead stored under aimem's own private, base64-encoded
`xattr-` header and uploaded under that key on next close/sync; the
`xattr-` header and uploaded under that key on next close/sync. The
`user.s3.meta.*`/`user.s3.tags.*` reflection keeps coming from the
native headers, so your value never appears back under the name you set
it — even though the write itself did persist, just not where you'd look
for it. Treat both namespaces as observe-only.
it. The write itself did persistjust not where you'd look for it.
Treat both namespaces as observe-only.

To attach durable, natively-visible metadata to an object, set it where
the object is produced (the writer/uploader that PUTs it), not via
Expand Down
6 changes: 3 additions & 3 deletions aimem/references/navigation.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,9 @@ mount point is the root of the configured prefix, not necessarily the bucket
itself: `ls <mount-root>` lists the top-level objects under that prefix, plus
the synthetic `.aimem/` namespace (e.g. `.aimem/annot/` for object
annotations). Every ordinary persistent file you read or write under the mount
maps to an object on the backing MinIO AIStor bucket; entries under `.aimem/`
are agent-native surfaces — object annotations are stored as native AIStor
object metadata, not as object bytes — and are not ordinary objects.
maps to an object on the backing MinIO AIStor bucket. Entries under `.aimem/`
are agent-native surfaces, not ordinary objects — object annotations are stored
as native AIStor object metadata, not as object bytes.

## How to find things

Expand Down
2 changes: 1 addition & 1 deletion aimem/references/search.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Other flags: `--no-recursive` (only keys directly under `--prefix`),
Connection comes from the standard flags/env (`--endpoint-url` /
`AIMEM_ENDPOINT_URL`, `--access-key` / `AIMEM_ACCESS_KEY`, `--secret-key` /
`AIMEM_SECRET_KEY`, optional `--session-token`). Output is one matching object
key per line, or — with `--content``name:line[:col]:text` matching lines
key per line. With `--content`, each matching line is `name:line[:col]:text`
(context lines on `name-…` separators). A stderr summary reports
`N matches in M files / K scanned`, adding `/ skipped`, `/ errors`, and
`(truncated)` when relevant.
Expand Down
10 changes: 5 additions & 5 deletions aimem/references/workspace.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,11 +27,11 @@ This means:
opening. aimem warns at mount if free space is below the
configured threshold.
- **Concurrent writers fight.** If two processes open the same path
for writing, whichever closes last wins — close order isn't
guaranteed to match open order — and the other's data is silently
overwritten. This is this mount's staged-upload policy (the last
`close()` is what gets uploaded), not a universal POSIX guarantee
worth re-stating here because the blast radius is the bucket.
for writing, whichever closes last wins, and the other's data is
silently overwritten. Close order isn't guaranteed to match open
order. This is this mount's staged-upload policy (the last
`close()` is what gets uploaded), not a universal POSIX guarantee,
and the blast radius is the bucket.

## Rename

Expand Down