# Notes intake — config, state, and scrubbing rules

Reference for the `capture-tickets-from-notes` skill and the `note-scout` agent.

## Where the config lives

The skill resolves configuration in this order (first hit wins):

1. A `## Meeting notes` section in the project's `CLAUDE.md`.
2. A `.gemma/notes-config.yml` file at the repo root.

Resolving from `CLAUDE.md` first mirrors how `gemma-dbt/validate-repo` resolves target-structure docs — projects that already document everything in `CLAUDE.md` don't need a second file.

### `.gemma/notes-config.yml` schema

```yaml
# Where the project's meeting notes live (required).
notes_dir: docs/meeting-notes/          # repo-relative path; markdown/txt notes

# Optional: an external transcript source. The LEAD pre-fetches these
# (credential boundary) — the skill/agent never calls the API itself.
api_source:
  type: fireflies                       # fireflies | gdrive
  # 1Password item REFERENCE only — never an inline token/secret.
  token_ref: "op://<vault>/<item>/<field>"

# Where approved tickets are posted (required). Tool-agnostic; clickup shown.
clickup:
  team_id: "<team_id>"                  # from any ticket URL: app.clickup.com/t/<team_id>/ID-…
  list_id: "<list_id>"                  # target list/space for new tickets
```

The same `<tool>:` block shape works for `asana:`, `notion:`, `jira:` — give whatever the connected MCP server or API needs to address the target backlog. Keep only **references** to secrets here, never values.

### Equivalent `CLAUDE.md` section

```markdown
## Meeting notes

- notes_dir: docs/meeting-notes/
- clickup team_id: <team_id>, list_id: <list_id>
- api_source: fireflies, token in op://<vault>/<item>/<field>   # optional
```

## State marker — `.gemma/notes-state.json`

Tracks what's already been processed so notes aren't re-proposed. Created on first run.

```json
{
  "processed": [
    { "path": "docs/meeting-notes/2026-06-18-standup.md", "hash": "<sha256>", "processed_at": "2026-06-18T10:04:00Z" }
  ],
  "transcripts": [
    { "id": "<fireflies_transcript_id>", "processed_at": "2026-06-18T10:04:00Z" }
  ],
  "posted_tickets": [
    { "ticket": "CU-abc123", "source": "docs/meeting-notes/2026-06-18-standup.md" }
  ]
}
```

- A note is **new** if its path is absent from `processed` *or* its `hash` changed (note edited/appended).
- `posted_tickets` lets dedup skip actions already turned into tickets.
- Commit this file to the project repo so the "new since last run" boundary is shared across teammates and machines. It holds only paths, hashes, and ticket IDs — no note content, so it's safe to commit.

## Scrubbing rules (the client-safety contract)

Tickets posted from notes must be generic and actionable. Apply every time, on every draft:

| Keep (generic) | Strip (client-specific) |
|---|---|
| The action — what needs doing | Client / company / person names |
| Discipline tag (`de`/`ae`/`da`/`ds`/`qa`) | Revenue, spend, and other business figures |
| Acceptance criteria, expressed generically | Raw quotes that embed client data |
| Source attribution: note **filename + date** | Client-specific schema / table / column names |
| Priority / due **only if the note states them** | Anything that identifies the engagement (URLs, IDs, emails) |

Rules of thumb:

- **Filename + date is the only provenance** that leaves the note. Never copy raw note content into a ticket.
- If an action can't be stated without a client specific, **write it generically and flag the gap** for the lead — don't pass the specific through.
- **Never invent** a priority or due date. Carry only what the note explicitly states.
- When unsure whether something is a specific, treat it as one and scrub it. A vaguer ticket costs a clarifying question; a leaked specific costs client trust.

## Connection-mode caveat

This path is **API-allowed, not Bedrock-gated** (unlike data tasks, which the hard QA gate blocks off-Bedrock). On the Anthropic API the raw notes pass through Anthropic during distillation — the scrub protects only what gets *posted*, not what gets *read*. For genuinely sensitive client notes, run the skill on **Bedrock** (`claude-db` / `bedrock-on`) so the note content stays in Gemma's AWS account. This is a recommendation the skill surfaces, not a hard block — the user chose convenience-with-scrubbing over gating.