jmap-metadata-types 0.4.0

# Agent Instructions — jmap-metadata-types

## 🧬 Sibling of the canonical jmap-mail-types — mirror its shape

This crate is a **sibling under the canonical `jmap-mail-types`
extension-types template**. Type-naming idioms, `#[non_exhaustive]`
policy, serde attribute style, doc-comment style, and test layout
must mirror `jmap-mail-types`. Differences are *only* the spec
content (draft-ietf-jmap-metadata-04 here; RFC 8621 in mail-types).
draft-04 defines no JMAP object type of its own, so this crate has
no data-object structs, `Property` enum, or `FilterCondition`; that
is a spec-mandated difference, not drift.

**The propagation rule** (workspace AGENTS.md "Canonical Templates"):

- If you reshape this crate in a way that diverges from
  `jmap-mail-types`, **change `jmap-mail-types` first, then
  propagate** to every other extension-types sibling in the same
  pass.
- If `jmap-mail-types` changes, propagate the change here in the
  same pass (or file a follow-up sweep bead before merging).
- A divergent sibling without a matching change on the canonical
  is a regression of the cookie-cutter intent — review will catch
  it.

Prefer non-breaking additions (new fields on `#[non_exhaustive]`
structs, new functions) over reshaping existing types.

This project uses **bd** (beads) for issue tracking. Run `bd prime`
for full workflow context.

## Before Starting Any Work

1. Read `PLAN.md` — module layout, design decisions, source material
2. Read the relevant draft-ietf-jmap-metadata-04 section before
   implementing any type
3. Cross-check the canonical sibling
   `~/PROJECT/crate-jmap/crate-jmap-mail-types/` for the type/serde
   pattern to follow
4. Run `bd ready` — check for open issues before creating new ones

## What This Is

JMAP Metadata extension data types (draft-ietf-jmap-metadata-04).
Types only — no method handlers. No async. Provides
`DataTypeMetadataInfo` (§1.2.1), `MetadataTextMatch` (§3.6),
namespace identifier validation (§2.1), and `JMAP_METADATA_URI`.
Consumed by `jmap-metadata-server` and `jmap-metadata-client`.

## Crate Family Context

```
jmap-metadata-types  ← this crate (sibling of canonical jmap-mail-types)
    ├── jmap-metadata-server
    └── jmap-metadata-client
```

When changing a public type or function, check that both consumers
still compile.

## Spec Reference

```
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-metadata-04   ← normative
~/PROJECT/IETF/specs/rfc8620.txt                     ← base protocol
```

**Before naming any field or type**, grep the draft text to confirm
the exact name. Field name mismatches cause silent serde failures.

## Non-Interactive Shell Commands

```bash
cp -f source dest       mv -f source dest       rm -f file
rm -rf directory        cp -rf source dest
```

Use `-o BatchMode=yes` for scp/ssh. Use `-y` for apt-get.

## Build & Test

```bash
cargo fmt --all
cargo clippy -p jmap-metadata-types -- -D warnings
cargo test -p jmap-metadata-types
RUSTDOCFLAGS="-D warnings" cargo doc -p jmap-metadata-types --no-deps
```

Run all four before considering any work done.

## Design Constraints (Settled)

| Decision | Choice |
|---|---|
| Async | None — sync only |
| Unsafe | Forbidden — `#[forbid(unsafe_code)]` |
| Dependencies | serde, serde_json only |
| Field names | Must match draft-ietf-jmap-metadata-04 exactly |
| Wire format | camelCase JSON — `#[serde(rename_all = "camelCase")]` |
| Test oracle | Hand-written JSON from spec examples — never from code under test |
| Attribute order | `#[non_exhaustive]` → `#[derive(...)]` → `#[serde(...)]` on every type |
| Per-type `metadata` fields | Not typed; round-trip via each data object's `extra` map (bd JMAP-ua37.4) |

## Subagent Guidance

- Spawn subagents for parallel work on independent modules
- Never spawn two subagents editing the same file
- Give each subagent the relevant draft section explicitly
- Escalate after 3 failed attempts at the same error

## Restrictions

- Push freely — `git push`, no `pull --rebase` ritual. If a push is rejected for any reason, stop and ask the human; do NOT `pull --rebase`, merge, force-push or `git reset` (workspace AGENTS.md "Git Commit and Push Policy")
- Do not use TodoWrite or markdown task lists — use `bd create`
- Do not add dependencies beyond serde, serde_json
- Do not add async, tokio, or axum
- Do not add method handler logic — types only
- Do not add fields or types not present in draft-ietf-jmap-metadata-04
  unless explicitly directed