@event4u/agent-config 6.0.0 → 6.1.0

package/dist/agent-src/commands/chat-history/show.md

@@ -1,113 +0,0 @@
----
-model_tier: medium
-name: chat-history-show
-pack: meta
-tier: 2
-cluster: chat-history
-sub: show
-skills: [chat-history]
-description: Show the status of the persistent chat-history log — file size, entry count, header fingerprint, age, and the last few entries
-suggestion:
-  eligible: false
-  rationale: "Status display only; no NL trigger distinct from 'show status'."
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-<!-- cloud_safe: noop -->
-
-# /chat-history show
-Inspect `agents/runtime/.agent-chat-history` — the JSONL log appended by the
-structural chat-history hooks (`ChatHistoryAppendHook`,
-`ChatHistoryHaltAppendHook`) for crash recovery.
-
-Shows:
-
-- Whether the file exists and whether logging is currently enabled
-- File size vs `max_size_kb`
-- Header metadata: schema version, `started`, `frequency`
-- Entry count and age of the oldest/newest entry
-- A peek at the last 3–5 entries so the user can see what was captured
-
-Read-only — this command never writes to the file.
-
-## When NOT to use
-
-- Wipe the file → delete `agents/runtime/.agent-chat-history` manually; it is
-  git-ignored and will be recreated on the next hook fire.
-- Configure logging behavior → edit `.agent-settings.yml` directly
-  (`chat_history.*`); see
-  [`layered-settings`](../../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules).
-
-## Steps
-
-### 1. Check if enabled
-
-Read `chat_history.enabled` from `.agent-settings.yml`. If `false` or
-the section is missing, say so and stop:
-
-```
-> 📒 chat-history is disabled (chat_history.enabled = false).
-> Set it to true in .agent-settings.yml to start logging.
-```
-
-### 2. Read status via helper
-
-Run `scripts/chat_history.py status`. The helper returns a JSON object
-with `exists`, `size_bytes`, `size_kb`, `entries`, `header`, and `path`.
-
-If `exists: false`, tell the user the file has not been created yet —
-it will be created on the next agent turn that writes an entry.
-
-### 3. Read last N entries
-
-Run `scripts/chat_history.py read --last 5` (or equivalent — see the
-helper's CLI). Capture timestamps and entry types without loading the
-full file.
-
-### 4. Present the summary
-
-Render a concise report:
-
-```
-> 📒 chat-history status
->
-> File:       agents/runtime/.agent-chat-history  ({size_kb} KB / {max_size_kb} KB)
-> Entries:    {entries}
-> Schema:     v{header.v}  (started {header.started})
-> Frequency:  {header.freq}
-> Overflow:   {on_overflow}
->
-> Last entries:
->   {ts_1}  {type_1}  {preview_1}
->   {ts_2}  {type_2}  {preview_2}
->   ...
-```
-
-Keep previews short (≤ 60 chars). Do not render the full entry text
-unless the user asks (avoids flooding the conversation with old log
-data, see [`token-efficiency`](../rules/token-efficiency.md)).
-
-### 5. Offer follow-ups (optional)
-
-If the file is close to `max_size_kb` (> 80 %), mention it — the next
-append may trigger overflow handling. To pull a specific prior
-session into the current chat verbatim, point the user at
-`/chat-history import`; to mine a prior session for project-improving
-learnings, `/chat-history learn`. The body filter on `s` is the v4
-isolation surface in both cases.
-
-## Gotchas
-
-- `agents/runtime/.agent-chat-history` is git-ignored. This command never commits.
-- The helper is the only way to read the file — do not cat or parse
-  the JSONL directly; entry shape is owned by `scripts/chat_history.py`.
-- If `exists: false` but the rule says logging is enabled, the file is
-  created lazily on the first append. That is expected — not an error.
-
-## See also
-
-- [`chat-history-platform-hooks`](../../../agents/settings/contexts/chat-history-platform-hooks.md) — the hook-only contract
-- [`agent-settings` template](../templates/agent-settings.md) — `chat_history.*` reference
-- [`scripts/chat_history.py`](../../../scripts/chat_history.py) — helper API (`status`, `read`, `sessions`, `prune-sessions`)

package/dist/agent-src/commands/fix/pr-bot-comments.md

@@ -1,157 +0,0 @@
----
-model_tier: medium
-name: fix-pr-bot-comments
-pack: engineering-base
-tier: 2
-cluster: fix
-sub: pr-bot-comments
-skills: [php-coder, quality-tools]
-description: Fix and reply to bot review comments (Copilot, Augment, Greptile, etc.) on a GitHub PR
-suggestion:
-  eligible: true
-  trigger_description: "address the Copilot/Greptile comments, fix the bot review feedback"
-  trigger_context: "open PR with bot review comments unresolved"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /fix pr-bot-comments
-## Input
-
-The user may or may not provide a PR URL.
-
-### PR detection
-
-1. If the user provides a GitHub PR URL → use that PR.
-2. If no URL is provided → **try to detect the PR automatically:**
-   - Determine the current Git branch (`git branch --show-current`).
-   - Search for an open PR on that branch via the GitHub API
-     (`GET /repos/{owner}/{repo}/pulls?head={owner}:{branch}&state=open`).
-   - If exactly one PR is found → tell the user: "I found PR #{number} ({title}) on branch `{branch}`. Is that the one?"
-   - Wait for confirmation before proceeding.
-   - If no PR or multiple PRs are found → ask the user for the PR URL.
-3. **Never** reuse a PR number from earlier in the conversation.
-
-## Mode selection
-
-After the PR is confirmed, ask the user (use numbered options per `user-interaction` rule):
-
-```
-> 1. Interactive — ask before each comment
-> 2. Automatic — handle all independently
-```
-
-- **Option 1** → follow the "Interactive flow" below.
-- **Option 2** → follow the "Auto flow" below.
-
-## Bot detection
-
-A comment is from a **bot** if the GitHub user has `type: "Bot"` or the login matches
-known bot accounts: `Copilot`, `github-actions[bot]`, `greptile[bot]`, `augment[bot]`,
-or any login ending in `[bot]`.
-
-## Instructions (shared)
-
-1. **Fetch all review comments** from the PR using the GitHub API (`/pulls/{number}/comments`).
-   Use `per_page: 100`. Filter for **bot comments** that have **no reply yet** from a human user.
-
-2. **For each unresolved bot comment**, read the affected file and surrounding context
-   to understand the code and the suggestion.
-
-3. **Report the total count** to the user: "Found X unresolved bot comments."
-
----
-
-## Interactive flow
-
-For each comment, present it to the user **before** taking action:
-
-### 1. Summarize the comment
-
-In the **user's language**, briefly explain:
-- Which file/line is affected
-- What the bot is suggesting
-- Your assessment: is it valid, partially valid, or not applicable?
-
-### 2. Offer options
-
-Present numbered options. Always include a "leave as-is" option. Examples:
-
-**If there's one clear fix:**
-> **Comment 1/3** — `WorkingTimeService.php:108`
-> Bot says: The guard condition only checks `job_start`, but the comment also mentions `job_stop`.
->
-> 1. Fix the comment (only mention `job_start`)
-> 2. Extend the guard condition (also check `job_stop`)
-> 3. Leave as-is, dismiss comment
-
-**If there are multiple valid approaches:**
-> **Comment 2/3** — `AbsencePlannerService.php:520`
-> Bot says: When an exception occurs mid-loop, log entries are missing.
->
-> 1. `writeLogBulk()` in einen `finally`-Block verschieben
-> 2. Die gesamte Schleife in eine DB-Transaction wrappen
-> 3. Leave as-is, dismiss comment
-
-### 3. Wait for the user's choice
-
-- Do NOT proceed until the user picks an option.
-- If the user asks a follow-up question, answer it before proceeding.
-- After the user chooses, apply the fix (or skip) and reply on GitHub.
-
-### 4. Move to the next comment
-
-Repeat until all comments are handled.
-
----
-
-## Auto flow
-
-Process all comments without asking. For each comment:
-
-1. Analyze whether the suggestion is valid.
-2. **If valid** — fix it and reply on GitHub.
-3. **If not valid** — reply on GitHub explaining why, do NOT change the code.
-
----
-
-## Common patterns to watch for
-
-- **Duplicate PHPDoc tags** → fix by keeping the more specific/typed version.
-- **Split PHPDoc blocks** → merge into a single docblock.
-- **Wrong PHPDoc tag order** → `@param` before `@return` before `@throws`.
-- **Conflicting PHPDoc types** → remove incorrect PHPDoc, trust the method signature.
-- **Broad ignore patterns / intentional config** → reply explaining rationale, don't change.
-- **Validation/logic bugs** → fix the code.
-
-## Reply style — write like a human developer, not an AI
-
-- The GitHub API token authenticates as the PR author. Write replies as if you ARE the developer.
-- Keep it casual, short, and natural. Like a real dev replying to a code review.
-- Vary your wording — never use the same opening phrase twice in a row.
-- Don't over-explain. A dev who fixed something doesn't write a paragraph about it.
-- Good examples: `"Good catch, fixed."`, `"Yep, consolidated into one docblock now."`,
-  `"Removed the duplicate 👍"`, `"That's intentional — [reason]"`
-- Never start multiple replies with "Fixed". Mix it up: "Done", "Good catch", "Yep", etc.
-
-### Bot icon prefix
-
-Read `personal.pr_comment_bot_icon` from `.agent-settings.yml`. If `true` (default),
-prefix every reply with `🤖 ` so reviewers can see at a glance that the reply was
-bot-authored.
-
-Example: `🤖 Good catch, fixed.`
-
-If `false` or `.agent-settings.yml` doesn't exist, do NOT add the prefix.
-
-## Replying via GitHub API
-
-Read `github.pr_reply_method` from `.agent-settings.yml` to determine the correct endpoint.
-See the `command-routing` skill → "GitHub API: Replying to PR review comments" for full details.
-
-## After all comments
-
-1. Run a PHP syntax check (`php -l`) on all modified files to verify nothing is broken.
-2. **Do NOT commit or push.** Just apply the fixes locally and reply to all comments on GitHub.

package/dist/agent-src/commands/fix/pr-developer-comments.md

@@ -1,163 +0,0 @@
----
-model_tier: medium
-name: fix-pr-developer-comments
-pack: engineering-base
-tier: 2
-cluster: fix
-sub: pr-developer-comments
-skills: [php-coder]
-description: Fix and reply to human reviewer comments on a GitHub PR
-suggestion:
-  eligible: true
-  trigger_description: "fix the human reviewer comments, address the developer feedback"
-  trigger_context: "open PR with unresolved human-reviewer comments"
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# /fix pr-developer-comments
-## Input
-
-The user may or may not provide a PR URL.
-
-### PR detection
-
-1. If the user provides a GitHub PR URL → use that PR.
-2. If no URL is provided → **try to detect the PR automatically:**
-   - Determine the current Git branch (`git branch --show-current`).
-   - Search for an open PR on that branch via the GitHub API
-     (`GET /repos/{owner}/{repo}/pulls?head={owner}:{branch}&state=open`).
-   - If exactly one PR is found → tell the user: "I found PR #{number} ({title}) on branch `{branch}`. Is that the one?"
-   - Wait for confirmation before proceeding.
-   - If no PR or multiple PRs are found → ask the user for the PR URL.
-3. **Never** reuse a PR number from earlier in the conversation.
-
-## Mode selection
-
-After the PR is confirmed, ask the user (use numbered options per `user-interaction` rule):
-
-```
-> 1. Interactive — ask before each comment
-> 2. Automatic — handle all independently
-```
-
-- **Option 1** → follow the "Interactive flow" below.
-- **Option 2** → follow the "Auto flow" below.
-
-## Human reviewer detection
-
-A comment is from a **human reviewer** if:
-- The GitHub user `type` is `"User"` (not `"Bot"`).
-- The login does NOT end in `[bot]`.
-- The user is NOT the PR author (don't process your own comments).
-
-## Instructions (shared)
-
-1. **Fetch all review comments** from the PR using the GitHub API (`/pulls/{number}/comments`).
-   Use `per_page: 100`. Also fetch **PR reviews** (`/pulls/{number}/reviews`) for top-level
-   review comments. Filter for **human reviewer comments** that have **no reply yet** from the PR author.
-
-2. **For each unresolved reviewer comment**, read the affected file and surrounding context
-   to understand the code and what the reviewer is asking for.
-
-3. **Report the total count** to the user: "Found X unresolved reviewer comments."
-
----
-
-## Interactive flow
-
-For each comment, present it to the user **before** taking action:
-
-### 1. Summarize the comment
-
-In the **user's language**, briefly explain:
-- Who wrote the comment (reviewer name/login)
-- Which file/line is affected
-- What the reviewer is requesting or asking
-- Your assessment: is it a valid concern, a question, a style preference, or a misunderstanding?
-
-### 2. Offer options
-
-Present numbered options. Always include a "skip" option. Adapt options to the comment type:
-
-**For a change request:**
-> **Comment 1/3** — @cjost1988 in `WorkingTimeService.php:108`
-> Reviewer asks: Why is the fallback `float`? `$time` is `$hours * 60`.
->
-> 1. Reply and explain why (no code change needed)
-> 2. Adjust type annotation to `float|int|string`
-> 3. Skip
-
-**For a bug report:**
-> **Comment 2/3** — @cjost1988 in `AbsencePlannerService.php:520`
-> Reviewer says: Race condition when two requests book simultaneously.
->
-> 1. Add locking mechanism (DB lock or cache lock)
-> 2. Reply: not relevant in current scope, create a ticket
-> 3. Skip
-
-**For a question (no code change needed):**
-> **Comment 3/3** — @cjost1988 in `KS21Client.php:42`
-> Reviewer asks: Is this fallback ever reached?
->
-> 1. Reply with explanation
-> 2. Skip
-
-### 3. Wait for the user's choice
-
-- Do NOT proceed until the user picks an option.
-- If the user wants to write a custom reply, let them dictate the text.
-- If the user asks a follow-up question, answer it before proceeding.
-- After the user chooses, apply the fix (or reply) and post on GitHub.
-
-### 4. Move to the next comment
-
-Repeat until all comments are handled.
-
----
-
-## Auto flow
-
-Process all comments without asking. For each comment:
-
-1. Analyze what the reviewer is requesting.
-2. **If it's a clear code fix** — fix it and reply on GitHub.
-3. **If it's a question** — reply with a concise explanation on GitHub.
-4. **If it's ambiguous or a design decision** — flag it to the user instead of guessing.
-   In auto mode, collect these and present them at the end: "These comments need your decision: ..."
-
----
-
-## Reply style — write like a human developer, not an AI
-
-- The GitHub API token authenticates as the PR author. Write replies as if you ARE the developer.
-- Keep it casual, short, and natural. Like a real dev replying to a code review.
-- Vary your wording — never use the same opening phrase twice in a row.
-- For reviewer questions: answer directly and concisely. Don't over-explain.
-- For fixes: confirm briefly what was changed.
-- Be respectful — these are colleagues, not bots. Don't dismiss feedback.
-- Good examples: `"Good point, fixed."`, `"Yep, that was a leftover — removed."`,
-  `"The fallback covers legacy data where getTime() returns a string."`
-- Never start multiple replies with the same phrase. Mix it up naturally.
-
-### Bot icon prefix
-
-Read `personal.pr_comment_bot_icon` from `.agent-settings.yml`. If `true` (default),
-prefix every reply with `🤖 ` so reviewers can see at a glance that the reply was
-bot-authored.
-
-Example: `🤖 Good point, fixed.`
-
-If `false` or `.agent-settings.yml` doesn't exist, do NOT add the prefix.
-
-## Replying via GitHub API
-
-Read `github.pr_reply_method` from `.agent-settings.yml` to determine the correct endpoint.
-See the `command-routing` skill → "GitHub API: Replying to PR review comments" for full details.
-
-## After all comments
-
-1. Run a PHP syntax check (`php -l`) on all modified files to verify nothing is broken.
-2. **Do NOT commit or push.** Just apply the fixes locally and reply to all comments on GitHub.

package/dist/agent-src/templates/agents/memory/architecture-decisions.example.yml

@@ -1,95 +0,0 @@
-# architecture-decisions.yml — indexed ADRs with path constraints
-#
-# Writer:   decision author at ADR time
-# Reader:   `feature-plan`, `api-design`, `blast-radius-analyzer`
-#           (consulted BEFORE proposing structural changes)
-# Expiry:   marked `deprecated` on reversal; NEVER deleted — history
-#           is the value. Supersession via `superseded_by`.
-# Location: agents/memory/architecture-decisions/<hash>.yml
-#           OR agents/memory/architecture-decisions.yml (single-file)
-#
-# The YAML is an **index**, not the decision doc. Each entry points
-# to a long-form ADR (Markdown, Notion, Confluence — wherever your
-# team writes them) and captures the machine-readable metadata an
-# agent needs: paths constrained, alternatives rejected, trade-offs.
-
-version: 1
-
-entries:
-  - id: 0007-tenant-boundaries
-    status: active                       # active | deprecated | archived
-    confidence: high
-    source:
-      - docs/adr/0007-tenant-boundaries.md
-      - https://github.com/example/repo/pull/842
-    owner: platform-team
-    last_validated: 2026-04-10
-    review_after_days: 365
-
-    # --- decision body ---
-    title: Tenant boundaries enforced by global scopes + dedicated DB
-    date: 2025-11-18
-    context: >
-      Multi-tenant SaaS; legal requirement to isolate tenant data at
-      rest. Prior approach (column-based scoping) leaked in three
-      incidents over six months.
-    decision: >
-      Adopt per-tenant database connections with a `TenantScope`
-      global scope on every tenant-owned Eloquent model. Raw DB
-      access is forbidden outside migrations.
-    alternatives_rejected:
-      - id: column-scoping-only
-        reason: Column scoping proven unsafe under complex joins.
-      - id: schema-per-tenant
-        reason: Operational cost of N schemas exceeded team capacity.
-    trade_offs:
-      - Higher connection pool usage — mitigated by connection reuse.
-      - Slower local dev onboarding — mitigated by seeder changes.
-    paths:                               # globs this ADR constrains
-      - app/Models/Tenant*/**
-      - config/database.php
-      - database/migrations/*_tenant_*.php
-    superseded_by: ""                    # id of replacement ADR
-
-  - id: 0012-money-representation
-    status: active
-    confidence: high
-    source:
-      - docs/adr/0012-money-representation.md
-    owner: finance-team
-    last_validated: 2026-03-20
-    review_after_days: 730
-
-    title: Money represented as integer cents end-to-end
-    date: 2026-01-05
-    context: >
-      Float precision errors in payment reconciliation caused
-      two customer-facing discrepancies.
-    decision: >
-      All monetary values are integer cents (smallest currency unit).
-      Floats appear only inside the formatter boundary, never in
-      storage, transport, or business logic.
-    alternatives_rejected:
-      - id: decimal-type
-        reason: DB decimal support uneven across MariaDB / SQLite
-          test environments; integer is unambiguous.
-    trade_offs:
-      - Every new developer must learn the convention — mitigated by
-        a dedicated `Money` value object with a strict type.
-    paths:
-      - app/Models/Invoice*.php
-      - app/Models/Payment*.php
-      - app/Services/Billing/**
-    superseded_by: ""
-
-# --- How to add an entry ---
-#
-# 1. Write the ADR as a Markdown doc FIRST. This index is a pointer,
-#    not a replacement.
-# 2. Link the ADR doc under `source`. At least one link is mandatory.
-# 3. List `paths` as globs the agent can match. Be generous — it is
-#    better to trigger the ADR on too many paths than too few.
-# 4. Fill `alternatives_rejected` even when it feels obvious. The
-#    agent's main job here is to stop re-litigating decisions.
-# 5. On reversal: keep the old entry, set `status: deprecated`, add
-#    the new entry with `superseded_by` pointing back. History stays.

package/docs/contracts/agent-memory-contract.md

@@ -1,159 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-12
----
-
-# Agent-Memory Contract (as expected by `agent-config`)
-
-**Purpose.** Freeze the interface `agent-config` currently expects from
-the sibling package `@event4u/agent-memory`, so when that package
-actually ships we can diff its real surface against this document in
-one place — instead of chasing drift across skills, commands, and
-helpers.
-
-**Ownership.** `agent-memory` is ours; we decide release timing. This
-doc is internal, not a spec handed to an external team. The
-authoritative spec-side documents live under
-[`agents/roadmaps/agent-memory/`](../../agents/roadmaps/archive/agent-memory/); this context
-is the **consumer-side snapshot** — what our wired code assumes today.
-
-Last refreshed: 2026-04-22.
-
-## What this doc is *not*
-
-- Not a replacement for the agent-memory retrieval-contract spec —
-  that lives in the agent-memory package and is the spec we hand to
-  the implementer.
-- Not a commitment that consumer code looks exactly like this forever
-  — it is a point-in-time pin.
-- Not an agent-facing skill. Humans read this when the package lands.
-
-## Expected backend states
-
-Defined in [`memory-access.md`](../../docs/guidelines/agent-infra/memory-access.md)
-and `scripts/memory_status.py`:
-
-| Status | Meaning | Agent-config behaviour |
-|---|---|---|
-| `absent` | Package not installed or CLI not on PATH | File fallback only |
-| `misconfigured` | Installed but `health()` fails within 2s | Warn once / session, fall back to file |
-| `present` | Installed and healthy within 2s | Route retrieval through package |
-
-Detection must be **bounded** (≤ 2s cold probe), **cached** per
-process, **non-raising** on probe failure.
-
-## Expected CLI surface
-
-Probed in `scripts/memory_status.py` via `_CLI_CANDIDATES`:
-
-- Executable on `PATH` as **`memory`** (canonical, ships in
-  `@event4u/agent-memory` v1.1+ as `package.json#bin.memory`),
-  **`agent-memory`** (planned alias), or **`agentmem`** (legacy).
-- Supports `health` subcommand emitting a v1 health envelope on stdout
-  (`{contract_version, status, backend_version, features, latency_ms}`)
-  and exiting non-zero on unhealthy.
-- Supports `retrieve <query> [--type T …] [--limit N] [--layer 1|2|3]
-  [--budget N] [--low-trust] [--repository ID]` emitting a v1
-  retrieval envelope on stdout (always JSON).
-
-The retrieval invocation is **semantic, not key-based** — see the
-"⚠️ Known contract drift" section below for the consumer-side
-implication.
-
-If the released package diverges from these names, we update
-`_CLI_CANDIDATES` in `memory_status.py` — not the other way round.
-
-## Expected retrieval shape (present path)
-
-Source of truth: the retrieval-contract spec in the agent-memory
-package. Consumer skills call the shared abstraction, not the package
-directly.
-
-**Request** (Python):
-
-```python
-retrieve(types=[…], keys=[…] or {…}, limit: int = 20, timeout_ms: int = 2000)
-```
-
-**Response** (v1 envelope) — mandatory fields per entry: `id`, `type`,
-`source ∈ {repo, operational}`, `confidence`, `body`. Optional:
-`trust`, `last_validated`, `shadowed_by`.
-
-Envelope: `contract_version`, `status ∈ {ok, partial, error}`,
-`entries`, `slices`, `errors`.
-
-## ⚠️ Known contract drift (consumer vs. spec)
-
-**Status: resolved at the consumer boundary.** The CLI / JSON output of
-`scripts/memory_lookup.py` already emits the v1 envelope with
-`source ∈ {repo, operational}`, `confidence`, `slices`, `status`, and
-`contract_version` — see `memory_lookup.py:320-345` (envelope
-assembly).
-
-What remains is **internal-only**: the private `Hit` dataclass inside
-`memory_lookup.py` still uses `source ∈ {curated, intake}` and `score`.
-No skill, command, or external consumer imports `Hit` directly — they
-all go through the public JSON surface, which is already spec-aligned.
-
-| Internal `Hit` field | Public envelope field | Visible to consumers? |
-|---|---|---|
-| `id`, `type` | `id`, `type` | yes — match |
-| `source ∈ {curated, intake}` | `source ∈ {repo, operational}` | no — translated at boundary |
-| `score ∈ [0,1]` | `confidence` | no — translated at boundary |
-| `path` | — | no — internal scoring signal |
-
-**Trigger to revisit:** if a second module starts importing the `Hit`
-dataclass directly (e.g. `memory_lookup.py` is split into multiple
-files and `Hit` becomes a public type), rename `Hit.source`/`Hit.score`
-to match the envelope so the boundary translation can be deleted.
-Until then, the internal naming is an implementation detail.
-
-There is also a **calling-convention drift** between the contract's
-key-based `retrieve(types, keys, limit)` and the package's
-semantic-only `retrieve(query, …)`. This is tracked separately and
-is the subject of an ongoing design decision (hybrid contract — keys
-synthesise into a query for the package path; file-fallback stays
-key-match).
-
-## Expected `propose()` / signal emission
-
-Shape used by `scripts/memory_signal.py` and the `/propose-memory`
-command: JSONL append-only drop-ins under
-`agents/memory/intake/*.jsonl`, one signal per line. When the package
-is present, the same payload is accepted by a `propose()` CLI or MCP
-call. File-drop is the always-works path.
-
-**Required fields** (keep in sync with `/propose-memory` command):
-`ts`, `type`, `key` (path or logical id), `observation`, `source`
-(`agent` or `human`), `session_id`.
-
-**Optional fields:**
-
-- `tags: string[]` — zero or more schema-routing labels from the
-  controlled vocabulary `{convention, invariant, gotcha, pattern}`.
-  Default `[]`. Producers (`/memory propose`, `/memory mine-session`)
-  emit tags; consumers (`/memory promote`) read **tag intersection**
-  to pick the curated YAML target when a signal carries two tags
-  (e.g. `[gotcha, invariant]` → primary `gotcha` JSONL, promote target
-  resolved by the reviewer at promotion time). See
-  [`memory-consolidation`](../../.agent-src.uncondensed/skills/memory-consolidation/SKILL.md)
-  § Phase 3 for the schema-routing table.
-- `confidence: low | medium | high` — producer-supplied estimate; the
-  inline-review hook in `/memory load` ranks the top-3 by this field.
-
-## Revisit triggers
-
-Q29 is **parked open**, not a blocker. Revisit when **one** of these
-holds:
-
-- `@event4u/agent-memory` ships a tagged release (any v0.x)
-- A consumer project explicitly asks for the `present` path
-- The agent-memory repo opens an integration PR against `agent-config`
-- We change the file fallback's public shape (then rewrite this doc
-  *before* the change lands)
-
-## See also
-
-- [`memory-access guideline`](../../docs/guidelines/agent-infra/memory-access.md)
-- [`scripts/memory_status.py`](../../.agent-src.uncondensed/templates/scripts/memory_status.py)
-- [`scripts/memory_lookup.py`](../../.agent-src.uncondensed/templates/scripts/memory_lookup.py)