feat: add intent endpoints

---

name: record-decision

description: Record an architecture or design decision as a numbered ADR (Architecture Decision Record) in the decisions/ folder, and link it from affected specs. Use when a design decision is made, changed, or reversed — in conversation, during a spec edit, or when the user says "record this decision", "why did we choose", or asks to document a trade-off.

---

# Record Decision

Decisions are stored as small, numbered, immutable markdown files in `decisions/` at the repo root. Specs state only the current rule; ADRs hold the reasoning. This keeps an auditable history as the architecture evolves.

## Workflow

1. **Number it.** List `decisions/` and take the next sequential number: `NNNN-short-kebab-title.md` (e.g. `0007-defer-capability-profile-catalog.md`). Create the folder if it doesn't exist.

2. **Write it** using the template below. Keep it under a page — context, the decision, and consequences. No implementation detail that belongs in a spec.

3. **Link it.** In each affected spec, keep the normative rule and add a reference to the ADR (e.g. "see ADR-0007"). Remove any embedded rationale the ADR now owns.

4. **Never rewrite an accepted ADR.** To change a decision, write a new ADR that supersedes the old one: set the old ADR's status to `superseded by ADR-NNNN` (the one permitted edit) and update spec links to point at the new ADR.

## Template

```markdown

# ADR-NNNN: <decision title>

**Status:** accepted            <!-- proposed | accepted | superseded by ADR-NNNN -->

**Date:** YYYY-MM-DD

**Affects:** <spec files / components this constrains>

## Context

What situation or problem forced a choice. Include the realistic options considered, one line each.

## Decision

The choice made, stated as a rule. One paragraph.

## Consequences

What becomes easier, what becomes harder, what is deferred, and the named trigger for revisiting (if any).

```

## Rules

- One decision per ADR. A discussion that settled three things produces three ADRs.

- Status `proposed` is allowed when the user has not yet confirmed; ask before marking `accepted`.

- If a decision is discovered embedded in a spec with no ADR (e.g. a "v1 decision" note), offer to backfill an ADR for it — don't backfill silently.

- ADR numbers are permanent; never renumber or reuse them.

---

name: spec-audit

description: Audit a set of architecture/spec documents for alignment, contradictions, stale references, structural drift, and undocumented decisions, producing a decision list for the user. Use when the user asks to verify, align, review, or clean up specs or architecture documents, or asks whether docs are consistent/coherent/up to date.

---

# Spec Audit

Verify that a set of interlinked spec documents forms one coherent, implementable contract. Works for a single component's doc set or a whole-platform architecture set.

## Workflow

1. **Establish the set.** Read every document in scope fully, including `decisions/` ADRs and the repo index (root `index.md`) if they exist. Note each doc's declared version, date, status, companion list, and ownership/scope statement (version/date/status live in the OKF frontmatter).

2. **Build the shared vocabulary.** List the identifiers that cross document boundaries: requirement IDs, section references, command/event/message names, table and column names, enum values, endpoint paths, schema identifiers, component names, ADR numbers, doc filenames.

3. **Check each category** (grep-verify, don't trust memory):

   - **Dangling references** — cited sections, requirement IDs, ADRs, options, or files that don't exist in the current set (including references to deleted/renamed docs and to artifacts defined only in out-of-scope docs).

   - **Contradictions** — the same rule stated differently in two places (scope of validation, who publishes what, when events fire, "exactly N cases" claims vs examples).

   - **Contract vs storage drift** — fields defined in interface contracts with no persistence mapping, type mismatches (declared vs stored), enum values with no producing/consuming path.

   - **Structural drift** — broken or non-sequential numbering (gaps in requirement IDs, missing section letters), docs missing the set's standard OKF frontmatter or revision history, companion lists, folder `index.md` files, or the repo index omitting set members.

   - **Undecided content** — "two options... recommendation" passages, open choices presented as spec text, conversational/chat-history phrasing.

   - **Undocumented decisions** — rationale or trade-off choices embedded in spec text with no corresponding ADR in `decisions/`; ADRs whose status contradicts current spec text (e.g. spec follows a superseded ADR).

   - **Examples vs normative text** — worked examples must match the current tables, subjects, field names, and rules exactly.

   - **ID stability** — if implementation code or tests exist, confirm no requirement ID referenced from code has been renumbered or reused.

4. **Classify and report.** Group findings as: blocking (broken/empty/contradictory), alignment (docs disagree — needs a decision), cleanup (style, numbering, artifacts), and out-of-scope-but-related. For each finding give file:line evidence, the concrete fix, and — where a decision is required — the options with one recommendation.

5. **Stop after reporting** unless the user asked for fixes. When they choose directions, apply each fix set-wide: every rename, renumber, or rewording is propagated to all documents; decisions taken during the fix pass are recorded per the `record-decision` skill; finish with a grep for stale identifiers (or the repo's `scripts/` reference-check script if one exists).

## Reporting format

Present findings as a numbered list grouped by the categories above, so the user can approve items by number. Lead with a one-line verdict on overall soundness. Do not mix the report with edits.

## Rules while fixing

- Never silently resolve a contradiction — the user picks the direction first.

- Mechanical fixes (typos, dangling refs, numbering) don't need approval once the user has asked for fixes.

- After edits, re-grep every identifier you changed across the whole set; the audit isn't done until that search returns clean.

---

name: spec-compliance

description: Check that an implementation change in this repo complies with the OOP architecture specs in /home/gpapathan/Desktop/architecture (OEG specs primarily). Use after implementing or modifying any feature, endpoint, mapper, persistence model, or flow — or when the user asks "does this match the spec", "is this compliant", or "check against the architecture". On any deviation the user decides whether to fix the code or change the spec; never silently deviate.

---

# Spec Compliance Check

The architecture contract for this repo lives in `/home/gpapathan/Desktop/architecture`. This

repo (open-exposure-gateway) implements the **OEG** component, so `oeg/` is the primary

spec set. Code and specs must never silently diverge: every deviation is either a bug in

the implementation or a pending change to the spec, and only the user decides which.

## Which specs govern what

| Change touches | Governing docs |

| --- | --- |

| NBI request/response shapes, endpoints, CAMARA mapping | `oeg/interface-contract.md`, `external-specs/` |

| Domain model, DB schema, repositories | `oeg/persistence-model.md` |

| Component structure, auth, policy, translation, SRM hand-off | `oeg/architecture.md` |

| App registration behavior | `oeg/app-registration-flow.md`, `oeg/translation-example-uc1.md` |

| App instantiation (single-zone, UC6/UC7) | `oeg/app-instance-flow.md` |

| Multi-zone deployments | `oeg/app-deployment-flow.md` |

| Cross-component contracts, terminology | `platform/`, SRM specs (`srm/`) for the southbound side |

| Rationale for any existing rule | `decisions/` ADRs |

## Procedure

1. **Scope the change.** Identify what the diff (or the change under discussion) touches

   and select the governing docs from the table above. Read the relevant sections fully —

   don't skim for keywords; the specs state rules in prose.

2. **Compare point by point.** For every point of contact between the change and the

   specs (a field name, an endpoint path, a state transition, an event, a schema column,

   a responsibility boundary), classify it as **conforming** or **deviating**. Also flag

   anything the change introduces that the specs don't cover at all (**unspecified**).

3. **If everything conforms:** report a short compliance summary listing what was checked

   against which docs, and stop.

4. **For each deviation or unspecified item:** do NOT pick a side yourself. Present it to

   the user with AskUserQuestion, one question per independent deviation, with options:

   - **Change the implementation** — bring the code in line with the spec.

   - **Change the spec** — the implementation reflects the intended design; update the

     spec document(s) in `/home/gpapathan/Desktop/architecture` to match.

   Include in the question the exact spec text (doc + section) and the exact code

   location so the user can decide without digging.

5. **Apply the decision.**

   - Implementation change: fix the code, then re-verify against the spec text.

   - Spec change: edit the governing doc(s) in `/home/gpapathan/Desktop/architecture`.

     That repo is an OKF v0.1 (Open Knowledge Format) bundle and its own `CLAUDE.md`

     states the editing contract — read and follow it: propagate identifier changes

     across the whole doc set, keep the YAML frontmatter (`type`, `title`,

     `description`, `tags`, `timestamp`, `component`, `version`, `status`), bump

     `version` and append to the revision-history section, and keep companion lists

     and `index.md` files in sync. Record the reasoning as an ADR via the

     `record-decision` skill (specs state the rule, ADRs hold the why).

6. **Report.** End with a summary: what conformed, what deviated, what the user decided,

   and what was changed where (code paths and spec paths).