Records: Customers, Meetings, Support, Fleet

Workspace content is markdown records with frontmatter, living in mounted content repos. Customer identities are read from mounted customers/*.md records, and each record domain exposes write-oriented commands. my sync --push publishes adopted changes.

my customers list [--json]
my customers list --identity --json
my customers add <domain|slug> [--name TEXT] [--domain DOMAIN] [--domain-confirmed] [--alias TEXT] [--partner ID]

my meetings list [--since DATE] [--customer ID] [--partner ID] [--json]
my meetings search <text>
my meetings get <id|path>
my meetings add <slug> [--date DATE] [--title TEXT] [--customer ID] [--attendees NAME] [--partner ID]

my support list [--since DATE] [--customer ID] [--identifier ID] [--claimed-by MEMBER] [--product ID] [--area TEXT] [--tag TEXT] [--feature-candidate] [--json]
my support search <text>
my support get <id|path>
my support add <slug> [--customer ID] [--identifier ID]... [--claimed-by MEMBER] [--observed-by MEMBER]... [--product ID] [--area TEXT] [--status open|workaround|resolved]

my fleet list [--status TEXT] [--customer ID] [--identifier ID] [--branch NAME] [--where KEY=VALUE] [--json]
my fleet search <text>
my fleet get <id|identifier|path>
my fleet add <id> [--customer ID] [--status TEXT] [--device TEXT] [--serial TEXT] [--identifier ID]...
my fleet set <id> KEY=VALUE...

Bare my meetings and my support use their safest useful action: they list records and accept the same filters as list. Subcommands remain available for search, retrieval, and creation.

When the qmd tool is installed, search uses it for higher-quality retrieval; otherwise a built-in scan applies. Single keywords match best.

Customer records

Customer identities live under customers/*.md in a mounted content repo, not in the manifest. Use my customers add <domain|slug> to scaffold one. A minimal record is:

---
id: sampleco.example.com
name: SampleCo
domain: sampleco.example.com
domain_confirmed: true
aliases:
  - sampleco
  - sc
partners:
  - integratorco
---

# SampleCo

my customers list reads these records, and customer filters accept IDs, domains, names, and aliases.

my customers list --identity --json > customer-identities.json generates a deterministic, least-privilege artifact for detached repository CI. The artifact contains only canonical IDs, domains, aliases, and source revision/freshness metadata; it omits names, partner links, note bodies, and local paths. Generate it where the customer mount is available, then provide only the JSON artifact to the detached job. Generation fails distinctly when the source is unavailable, dirty, or out of sync, so CI can distinguish an empty identity set from an untrustworthy projection.

Meetings

A meeting note is a dated journal entry: what was discussed, decided, and assigned. my meetings add <slug> scaffolds the record in the meetings content root; a slug that starts with YYYY-MM-DD sets the date. Attendees and partners are repeatable flags, each occurrence one literal value.

Support records

A support record is an anonymized problem-to-solution story: problem, context, solution, validation. The body stays anonymized; linkable attribution lives in frontmatter:

• --customer — the canonical customer ID (see my customers list).
• --identifier, repeatable — every device, order, workstation, or asset identifier that applies, so recurrence on the same equipment is discoverable later.
• --claimed-by — the org member who worked it; --observed-by, repeatable, for others involved.
• approved_by stays empty unless the operator explicitly signs off.

Fleet records

The fleet is a registry, not a journal: one record per deployed instance, keyed by a stable id, updated in place. State history is the record's git log.

my fleet get resolves any identifier — sales order, functional location, serial, hostname — and lists related support records found by shared identifiers. Its output ends with the concrete next step: a seeded my support add command carrying the customer and every identifier, ready to run when no relevant record exists yet.

Record workflow transitions with my fleet set <id> status=<value>, then publish with the suggested my sync --push --message command so each transition is a readable git commit.

The built-in fleet work contract ties these together — see Guidance and Contract.

Adoption: why your file did not publish

my sync --push only publishes content it knows is intentional. Records created by the CLI are adopted automatically (Git intent-to-add). A file you created by hand stays held until you adopt it:

my record adopt <path>

This is the difference between "scratch file that happens to be in a content mount" and "record the organization should see."

Sessions and records

When your current directory is inside an active session (sessions/<id>), record commands write to that session's mount worktree instead of the base mount — session work does not leak until you finish the session. See Sessions.

Pending session work only holds a base publish or land when the changed file paths overlap. Unrelated base and session records can proceed independently; if Git cannot prove the path sets, My AI keeps the existing fail-closed hold.