plugin 0.2.2

2026-06-05 00:49:20 -05:00
parent 67acf8fd52
commit d37b248747
115 changed files with 5565 additions and 0 deletions
@@ -0,0 +1,3 @@
 241265fbe6830934a9a4ad3e69335f64a42153b663aa5b0017cb1ea1217b2bab
 https://echoapi.alwisp.com
@@ -0,0 +1,9 @@
 {
  "name": "goldbrain-memory",
  "version": "0.1.0",
  "description": "Persistent memory via the goldbrain Obsidian vault over the Local REST API. Reads and writes notes across Claude/CoWork sessions using direct REST calls — no MCP server required.",
  "author": {
    "name": "Jason"
  },
  "keywords": ["memory", "obsidian", "notes", "persistence", "goldbrain"]
 }
@@ -0,0 +1,59 @@
 # goldbrain-memory
 Persistent memory for Claude via the **goldbrain** Obsidian vault, using the [Obsidian Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api).
 Reads and writes notes across Claude/CoWork sessions using direct REST calls — no MCP server required. Built for **Bryan Gilliom** (CEO, Message Point Media) as the primary operator; Jason is the vault architect.
 ## What it does
 - Loads operator preferences, current context, and relevant project notes at the start of substantive conversations
 - Writes facts, preferences, and decisions Bryan asks Claude to remember
 - Logs working sessions so future conversations can pick up where they left off
 - Defers to the vault's own `BOOTSTRAP.md` to verify and repair structure on first use
 ## Configuration
 The plugin is hardcoded for:
 - **Server:** `https://goldbrainapi.mpm.to` (reverse proxy → Obsidian Local REST API on `192.168.86.15:27124`)
 - **API Key:** stored in the skill (personal plugin, not for distribution)
 The endpoint presents a **valid TLS certificate**, so `-k` is not required. The bearer key lives only in the plugin — never inside the vault (per the vault's own safety rules).
 ## Vault layout (root-addressed)
 ```
 /vault/
 ├── CLAUDE.md  STRUCTURE.md  BOOTSTRAP.md  spinup.md  index.md  README.md
 ├── inbox/        (captures, imports, processing-log)
 ├── journal/      (daily, weekly, monthly, templates)
 ├── projects/     (active, incubating, on-hold, archived)
 ├── areas/        (business, personal, learning, systems)
 ├── resources/    (concepts, references, people, meetings, source-material)
 ├── decisions/    (by-date, by-project)
 ├── reviews/      (weekly, monthly, quarterly, annual)
 ├── archive/      (notes, projects, imports)
 └── _agent/
    ├── context/        ← task-scoped context bundles
    ├── memory/         ← working / episodic / semantic
    ├── sessions/       ← YYYY-MM-DD-HHMM-<slug>.md
    ├── templates/      ← canonical note templates
    ├── outputs/        ← briefs / drafts / summaries / synthesis
    ├── skills/         ← active / archived
    └── heartbeat/
 ```
 ## First run
 The vault ships its own `BOOTSTRAP.md`. On first use the skill reads `/vault/BOOTSTRAP.md`; if present it follows that preflight, and if absent (a fresh empty vault) it offers to bootstrap.
 ## Skills
 | Skill | Triggers |
 |-------|----------|
 | `goldbrain-memory` | "remember that", "save to memory", "what do you know about me", "load my profile", "check my notes", "log this decision", "add to my inbox" — and proactively at the start of substantive conversations |
 ## Requirements
 - Obsidian running on the backend with the [Local REST API plugin](https://github.com/coddingtonbear/obsidian-local-rest-api) enabled (binding host `0.0.0.0`)
 - HTTPS access to `https://goldbrainapi.mpm.to` from the Claude/CoWork session environment
@@ -0,0 +1,233 @@
 ---
 name: goldbrain-memory
 description: Use the goldbrain Obsidian vault as persistent memory across Claude/CoWork sessions. Triggers when the operator says "remember that", "remember this", "save to memory", "what do you know about me", "load my memory", "load my profile", "what did we discuss before", "check my notes", "what's my context", "what are my preferences", "log this decision", "add to my inbox", or starts a new project that should be tracked. Also triggers proactively at the start of substantive conversations to load operator context, and at the end to log session outcomes.
 ---
 # Goldbrain Memory
 Use the **goldbrain** Obsidian vault as persistent memory. Read context accumulated across sessions; write things the operator asks to be remembered.
 The primary operator is **Bryan Gilliom** (CEO, Message Point Media). Unless stated otherwise, "the operator" means Bryan. Jason is the vault's architect, not the day-to-day user. Write memory in third person ("Bryan prefers X", not "I prefer X").
 ## API Configuration
 All calls use these constants — hardcoded for this personal plugin:
 ```
 OBSIDIAN_BASE = https://goldbrainapi.mpm.to
 OBSIDIAN_KEY  = fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8
 ```
 The endpoint has a **valid TLS certificate**, so `-k` is not needed (add it only if the cert ever changes to self-signed). Always pass the `Authorization: Bearer` header. Paths address the vault **at its root** (e.g. `/vault/_agent/...`).
 Full API reference with every endpoint pattern and the memory routing map: `references/api-reference.md`. Vault layout and frontmatter conventions: `references/vault-layout.md`.
 ## When to Load Memory
 Load at the start of any substantive conversation — anything beyond a single quick factual question. The signal: the operator is starting work, planning, asking for help with something that has state, or referencing prior discussions.
 Do NOT narrate this loading. Reading memory is expected behavior.
 ### Loading procedure
 **Step 1 — Confirm the vault is bootstrapped:**
 ```bash
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/BOOTSTRAP.md"
 ```
 If this returns 404, the vault is not set up. Follow `references/bootstrap.md` before doing anything else.
 **Step 2 — Read operator preferences (the profile):**
 ```bash
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/_agent/memory/semantic/operator-preferences.md"
 ```
 **Step 3 — Read active context and the latest session:**
 ```bash
 # Current task-scoped context bundle
 curl -s -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/_agent/context/current-context.md"
 # List recent session logs, then read the most relevant
 curl -s -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/_agent/sessions/"
 ```
 **Step 4 — If a specific project is in play, list active projects and read the best match:**
 ```bash
 curl -s -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/projects/active/"
 curl -s -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/projects/active/<slug>.md"
 ```
 Optionally read today's daily note at `/vault/journal/daily/YYYY-MM-DD.md` for current priorities and open loops.
 ## When to Write Memory
 Write when the operator:
 - States a fact, preference, or commitment worth keeping ("I prefer X", "we use uv not pip", "standup is Tuesday at 10")
 - Makes a non-obvious decision worth recording
 - Says "remember that", "save this", "log this", "add to memory", "note that"
 - Finishes a meaningful working session future sessions should pick up
 Write in third person about Bryan. Every note carries the canonical frontmatter (see below). Agent-generated notes set `agent_written: true`.
 ### Append to a file (default — additive entries)
 Write content to a temp file first to handle multi-line markdown cleanly, then POST:
 ```bash
 cat > /tmp/obs_entry.md << 'OBSEOF'
 - 2026-06-02: <your entry here>
 OBSEOF
 curl -s -X POST \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_entry.md \
  "https://goldbrainapi.mpm.to/vault/inbox/captures/inbox.md"
 ```
 POST appends to the end of a file (creating it if absent). Use it for inbox captures, log sections, and daily-note Agent Log entries.
 ### Patch a specific heading (targeted update)
 **Heading targets use the FULL heading path, `::`-delimited from the top-level heading** — a bare subheading name fails with `invalid-target`. For example, `## Fact / Pattern` under the `# Operator Preferences` H1 is targeted as `Operator Preferences::Fact / Pattern`. When unsure of the exact path, read the document map first (see below).
 ```bash
 cat > /tmp/obs_patch.md << 'OBSEOF'
 Bryan prefers status updates that lead with the decision.
 OBSEOF
 curl -s -X PATCH \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Operation: append" \
  -H "Target-Type: heading" \
  -H "Target: Operator Preferences::Fact / Pattern" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_patch.md \
  "https://goldbrainapi.mpm.to/vault/_agent/memory/semantic/operator-preferences.md"
 ```
 Use `Operation: replace` to overwrite a section entirely (e.g. a project's `Project Name::Current status`). Percent-encode non-ASCII characters in the `Target` header; spaces are fine.
 **Discover exact heading paths** when unsure — GET the note with the document-map Accept header:
 ```bash
 curl -s -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Accept: application/vnd.olrapi.document-map+json" \
  "https://goldbrainapi.mpm.to/vault/_agent/memory/semantic/operator-preferences.md"
 ```
 It returns `{ "headings": [...], "blocks": [...], "frontmatterFields": [...] }` — copy the heading string verbatim into `Target`.
 ### Create or overwrite a file (PUT)
 ```bash
 cat > /tmp/obs_file.md << 'OBSEOF'
 ---
 type: project
 status: active
 created: 2026-06-02
 updated: 2026-06-02
 tags: []
 agent_written: true
 source_notes: []
 ---
 # Project Name
 ## Current status
 ...
 ## Related
 - [[journal/daily/2026-06-02]]
 OBSEOF
 curl -s -X PUT \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_file.md \
  "https://goldbrainapi.mpm.to/vault/projects/active/my-project.md"
 ```
 The API creates intermediate directories automatically.
 ### Search the vault
 ```bash
 curl -s -X POST \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/search/simple/?query=your+search+terms"
 ```
 ## Where to Write
 | Situation | File / path | Method |
 |-----------|-------------|--------|
 | Unsure where it goes / quick capture | `_agent/.../` → use `inbox/captures/inbox.md` (date-prefixed line) | POST |
 | Operator preference or durable fact | `_agent/memory/semantic/operator-preferences.md` (append under the right heading) | PATCH |
 | Other durable facts / patterns | `_agent/memory/semantic/<slug>.md` | PUT |
 | What happened (event record) | `_agent/memory/episodic/<slug>.md` | PUT |
 | Short-lived working state | `_agent/memory/working/<slug>.md` | PUT |
 | Task-scoped context / focus | `_agent/context/current-context.md` | PATCH / PUT |
 | Working session ended with substance | `_agent/sessions/YYYY-MM-DD-HHMM-<slug>.md` | PUT |
 | Long-running project state | `projects/active/<slug>.md` | PUT + PATCH |
 | Non-obvious decision (ADR) | `decisions/by-date/YYYY-MM-DD-<slug>.md` (mirror into `by-project/`) | PUT |
 | Person context | `resources/people/<name>.md` | PUT / PATCH |
 | Concept / reference note | `resources/concepts/` or `resources/references/` | PUT |
 | Daily activity / Agent Log | `journal/daily/YYYY-MM-DD.md` | POST / PATCH |
 Never delete files unless the operator explicitly asks. Memory is append-friendly; deletion is destructive.
 ## Session Logging
 At the end of substantive conversations (ones that produced decisions, artifacts, or commitments), create a session log. Ask once if unsure: "Want me to log a session note for this?"
 Session logs go in `_agent/sessions/YYYY-MM-DD-HHMM-<slug>.md`. See `references/session-log-template.md` for the exact format.
 ```bash
 cat > /tmp/obs_session.md << 'OBSEOF'
 <session log content — see references/session-log-template.md>
 OBSEOF
 curl -s -X PUT \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_session.md \
  "https://goldbrainapi.mpm.to/vault/_agent/sessions/2026-06-02-1430-my-session.md"
 ```
 Then append a one-line entry to the daily note's **Agent Log** section.
 ## Vault Unreachable
 If the API returns a connection error, timeout, or `502`, tell the operator once that the memory vault is unreachable (a `502` usually means Obsidian/the REST plugin is not running on the backend), then proceed without memory. Do not retry repeatedly.
 ## Style Rules
 - Write in third person about Bryan: "Bryan prefers X", not "I prefer X".
 - Do not attribute Jason's design preferences to Bryan — capture Bryan's preferences only from observed interactions.
 - Every memory file has canonical YAML frontmatter — see `references/vault-layout.md`.
 - Set `agent_written: true` on agent-generated notes and list `source_notes` (plain relative paths, not links).
 - **Never put `[[wikilinks]]` in frontmatter** — YAML parses them as nested lists and the links break in Obsidian's reading view. Put all cross-references in a `## Related` section in the note **body** as a bulleted list of `[[links]]`.
 - Use Obsidian wiki links (`[[note name]]`) freely in the note **body** for cross-references.
 - Keep entries short and focused. Fewer, sharper entries beat many noisy ones.
 - About to write something large or sensitive? Show the operator the content first and confirm.
 ## What This Skill Does Not Do
 - Does not replace reasoning. The vault is reference material — apply judgment.
 - Does not auto-summarize the whole vault. Read targeted files, not everything.
 - Does not store passwords or secrets, and never writes the API key into a vault note. If asked to "remember my password is X", decline and suggest a password manager.
@@ -0,0 +1,207 @@
 # Goldbrain — Obsidian Local REST API Reference
 Server: `https://goldbrainapi.mpm.to` (reverse proxy → Obsidian Local REST API on `192.168.86.15:27124`)
 Auth header: `Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8`
 The endpoint has a **valid TLS certificate** — `-k` is not required. Paths address the vault at its **root**.
 ---
 ## Reading Files
 ```bash
 # Read any file by vault path
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/_agent/context/current-context.md"
 ```
 Returns raw file content (text/markdown). On 404, the file does not exist.
 ```bash
 # Read a specific heading's content only
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/_agent/memory/semantic/operator-preferences.md/heading/Operator"
 ```
 Nested headings: separate levels with `::` (URL-encode spaces as `%20`):
 ```
 /vault/path/to/note.md/heading/Work%3A%3AMeetings
 ```
 ---
 ## Listing Directories
 ```bash
 # List contents of a directory (trailing slash required)
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/_agent/sessions/"
 ```
 Returns JSON: `{ "files": [...], "folders": [...] }`.
 ---
 ## Appending Content (POST)
 `POST` appends to the **end** of an existing file. Creates the file if it doesn't exist.
 ```bash
 cat > /tmp/obs_entry.md << 'OBSEOF'
 - 2026-06-02: your entry here
 OBSEOF
 curl -s -X POST \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_entry.md \
  "https://goldbrainapi.mpm.to/vault/inbox/captures/inbox.md"
 ```
 ---
 ## Creating or Overwriting Files (PUT)
 `PUT` creates a new file or fully overwrites an existing one. Intermediate directories are created automatically.
 ```bash
 cat > /tmp/obs_file.md << 'OBSEOF'
 ---
 type: session-log
 status: complete
 created: 2026-06-02
 updated: 2026-06-02
 tags: [agent, session]
 agent_written: true
 source_notes: []
 ---
 # content here
 ## Related
 - [[projects/active/some-project]]
 OBSEOF
 curl -s -X PUT \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_file.md \
  "https://goldbrainapi.mpm.to/vault/_agent/sessions/2026-06-02-1430-my-session.md"
 ```
 ---
 ## Patching a Specific Section (PATCH)
 `PATCH` edits inside a file without rewriting it. Target and operation are set via headers.
 ### Append under a heading
 **Heading targets must be the FULL heading path, `::`-delimited from the top-level heading.** A bare subheading name returns `400 invalid-target` (errorCode 40080). Example: `## Fact / Pattern` nested under `# Operator Preferences` → `Target: Operator Preferences::Fact / Pattern`. Percent-encode non-ASCII characters (e.g. `H%C3%A9llo`); spaces are fine.
 ```bash
 cat > /tmp/obs_patch.md << 'OBSEOF'
 Bryan prefers concise status updates — lead with the decision.
 OBSEOF
 curl -s -X PATCH \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Operation: append" \
  -H "Target-Type: heading" \
  -H "Target: Operator Preferences::Fact / Pattern" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_patch.md \
  "https://goldbrainapi.mpm.to/vault/_agent/memory/semantic/operator-preferences.md"
 ```
 ### Discover heading / block / frontmatter targets
 When unsure of the exact heading path, GET the note with the document-map Accept header:
 ```bash
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Accept: application/vnd.olrapi.document-map+json" \
  "https://goldbrainapi.mpm.to/vault/_agent/memory/semantic/operator-preferences.md"
 ```
 Returns `{ "headings": [...], "blocks": [...], "frontmatterFields": [...] }`. Copy the heading string verbatim into `Target`.
 ### Replace a heading's content entirely
 Same call with `Operation: replace` — e.g. to refresh a project's `Project Name::Current status`.
 ### Prepend under a heading
 Same call with `Operation: prepend`.
 ### Patch a frontmatter field
 ```bash
 curl -s -X PATCH \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  -H "Operation: replace" \
  -H "Target-Type: frontmatter" \
  -H "Target: updated" \
  -H "Content-Type: application/json" \
  --data '"2026-06-02"' \
  "https://goldbrainapi.mpm.to/vault/projects/active/vault-foundation.md"
 ```
 ---
 ## Searching
 ```bash
 curl -s -X POST \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/search/simple/?query=weekly+review"
 ```
 Returns an array of `{ filename, score, matches: [{ context, match }] }`.
 ---
 ## Deleting Files
 ```bash
 curl -s -X DELETE \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/archive/notes/old-note.md"
 ```
 Only on explicit operator request. Deletion is destructive.
 ---
 ## URL-Encoding Notes
 - Path separators (`/`) in the vault path are **literal** — do not encode them.
 - Spaces in filenames or heading targets in a URL: use `%20`.
 - Nested heading levels in a URL path: use `%3A%3A` for `::`.
 - Heading text in the `Target:` header: the **full heading path** joined by `::` (e.g. `Operator Preferences::Fact / Pattern`), no `#`; spaces are fine; percent-encode non-ASCII.
 ---
 ## Memory Routing Map
 | Situation | Vault path | Method |
 |-----------|-----------|--------|
 | Quick capture / unsorted | `inbox/captures/inbox.md` (date-prefixed line) | POST |
 | Raw imported material | `inbox/imports/` | PUT |
 | Operator preference / durable fact | `_agent/memory/semantic/operator-preferences.md` | PATCH |
 | Other durable facts, patterns | `_agent/memory/semantic/<slug>.md` | PUT |
 | Event record (what happened) | `_agent/memory/episodic/<slug>.md` | PUT |
 | Short-lived, time-boxed state | `_agent/memory/working/<slug>.md` | PUT |
 | Task-scoped context / focus | `_agent/context/current-context.md` | PATCH / PUT |
 | Working-session log | `_agent/sessions/YYYY-MM-DD-HHMM-<slug>.md` | PUT |
 | Long-running project state | `projects/active/<slug>.md` | PUT + PATCH |
 | Non-obvious decision (ADR) | `decisions/by-date/YYYY-MM-DD-<slug>.md` (mirror `by-project/`) | PUT |
 | Person context | `resources/people/<name>.md` | PUT / PATCH |
 | Concept / reference note | `resources/concepts/` or `resources/references/` | PUT |
 | Daily activity / Agent Log | `journal/daily/YYYY-MM-DD.md` | POST / PATCH |
 | Periodic review | `reviews/{weekly,monthly,quarterly,annual}/` | PUT |
 **Slug rules:** kebab-case, ASCII, ~40 chars max. Every file carries canonical frontmatter (see `vault-layout.md`).
@@ -0,0 +1,37 @@
 # Bootstrap Procedure
 The goldbrain vault ships its **own** `BOOTSTRAP.md` at the vault root — that file is the canonical preflight/repair manifest. This plugin defers to it rather than duplicating the logic.
 ## Normal case — vault already bootstrapped
 At session start, read the in-vault manifest:
 ```bash
 curl -s \
  -H "Authorization: Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8" \
  "https://goldbrainapi.mpm.to/vault/BOOTSTRAP.md"
 ```
 If it returns content (200), the vault is set up. Skim its preflight checklist, then read `CLAUDE.md` for the operating contract and proceed with the loading procedure in `SKILL.md`. The in-vault `BOOTSTRAP.md` describes how to repair any missing folders/files; follow it if something is absent. **Never overwrite an existing file** during repair — generate only what is missing.
 ## Fresh-vault case — BOOTSTRAP.md returns 404
 This means the REST API is pointed at an empty vault. Confirm with the operator once:
 > "The goldbrain vault looks empty — there's no `BOOTSTRAP.md`. The standard scaffold (control docs, folder tree, templates, seed notes) needs to be loaded before I can use it as memory. Want me to create the core seed files now?"
 If yes, create the minimum viable seed with `PUT` (the API creates intermediate directories automatically), then let the vault's own structure grow from there:
 1. `CLAUDE.md` — operating contract and session protocol
 2. `BOOTSTRAP.md` — preflight/repair manifest
 3. `STRUCTURE.md` — layout, taxonomy, frontmatter standard
 4. `index.md` — navigation hub
 5. `_agent/memory/semantic/operator-preferences.md` — operator profile (empty, no fabricated facts)
 6. `_agent/context/current-context.md` — empty context bundle
 7. `inbox/captures/inbox.md` — capture file
 Prefer copying the full prepared scaffold into the Obsidian vault folder over reconstructing it by hand — it is the source of truth for goldbrain's structure.
 ## After bootstrap
 Tell the operator briefly what was created, append a line to the daily note's **Agent Log**, and write a session log in `_agent/sessions/`. Do not over-explain — they can browse the vault.
@@ -0,0 +1,108 @@
 # Session Log Template
 Session logs go in: `_agent/sessions/YYYY-MM-DD-HHMM-<slug>.md`
 The slug describes what the session was about in 2–5 words, kebab-case.
 Examples: `2026-06-02-1430-goldbrain-plugin-build.md`, `2026-05-14-0900-q1-review-prep.md`.
 Keep logs focused. Capture the goal, what was read/done, decisions, outputs, open threads, and the next step. This matches the vault's `_agent/templates/session-log-template.md`.
 ---
 ## Template
 ```markdown
 ---
 type: session-log
 status: complete
 created: 2026-06-02T14:30
 updated: 2026-06-02T14:30
 tags: [agent, session]
 agent_written: true
 source_notes: []
 session_date: 2026-06-02
 client: claude-code
 ---
 # Session Log
 ## Goal
 One line — what this session set out to do.
 ## Notes Read
 - [[note]] — why it was relevant
 (omit if none)
 ## Actions Taken
 Brief narrative or bullets of what was done.
 ## Decisions Made
 - Decision — why
 (omit section if none)
 ## Outputs Created
 - `path/or/filename` — what it is
 (omit section if none)
 ## Open Threads
 - [ ] unresolved question or next step
 (omit section if none)
 ## Suggested Next Step
 One sentence: what to do first next time on this topic.
 ## Related
 - [[wikilinks go here, in the body — never in frontmatter]]
 ```
 ---
 ## Example
 ```markdown
 ---
 type: session-log
 status: complete
 created: 2026-06-02T14:30
 updated: 2026-06-02T14:30
 tags: [agent, session, plugin]
 agent_written: true
 source_notes: ["resources/references/obsidian-local-rest-api.md"]
 session_date: 2026-06-02
 client: claude-code
 ---
 # Session Log
 ## Goal
 Build and package the goldbrain-memory CoWork plugin against the live vault.
 ## Notes Read
 - [[BOOTSTRAP]], [[STRUCTURE]], [[_agent/memory/semantic/operator-preferences]]
 ## Actions Taken
 Verified the REST API end-to-end, confirmed the scaffold copied into the live vault,
 created missing empty folders, and built the plugin (SKILL + 4 reference files).
 ## Decisions Made
 - Vault addressed at root (no `Projects/agents/` prefix) — goldbrain is a dedicated vault.
 - Key hardcoded in the plugin (not in the vault) — personal plugin, per the reference pattern.
 ## Outputs Created
 - `goldbrain-memory.plugin` — installable CoWork plugin
 ## Open Threads
 - [ ] Validate Claude Code direct filesystem access to the vault host.
 ## Suggested Next Step
 Install the plugin and run a live load/write through it to confirm the skill triggers.
 ## Related
 - [[projects/active/vault-foundation]]
 - [[resources/references/obsidian-local-rest-api]]
 ```
 After writing the log, append a one-line entry to the daily note's **Agent Log** section.
 > **Reminder:** wiki links go in the body (e.g. this `## Related` section), never in YAML
 > frontmatter. `source_notes` in frontmatter holds plain relative path strings, not `[[links]]`.
@@ -0,0 +1,146 @@
 # Vault Layout & Frontmatter Conventions
 Mirrors the canonical conventions defined in the vault's own `STRUCTURE.md` and `BOOTSTRAP.md`. If those change, they are the source of truth.
 ## Folder Map (root-addressed)
 ```
 /vault/
 ├── CLAUDE.md          ← operating contract + session protocol
 ├── STRUCTURE.md       ← layout, taxonomy, frontmatter standard
 ├── BOOTSTRAP.md       ← preflight/repair manifest (read first)
 ├── spinup.md  index.md  README.md
 ├── inbox/
 │   ├── captures/      ← quick captures (inbox.md), date-prefixed lines
 │   ├── imports/       ← raw imported material
 │   └── processing-log/
 ├── journal/
 │   ├── daily/         ← YYYY-MM-DD.md (has an "Agent Log" section)
 │   ├── weekly/  monthly/
 │   └── templates/
 ├── projects/
 │   ├── active/        ← <slug>.md, long-running project state
 │   ├── incubating/  on-hold/  archived/
 │   └── project-template.md
 ├── areas/             ← business / personal / learning / systems
 ├── resources/
 │   ├── concepts/  references/  meetings/  source-material/
 │   └── people/        ← <name>.md
 ├── decisions/
 │   ├── by-date/       ← YYYY-MM-DD-<slug>.md (ADR-style)
 │   ├── by-project/    ← mirror by project
 │   └── decision-template.md
 ├── reviews/           ← weekly / monthly / quarterly / annual
 ├── archive/           ← notes / projects / imports
 └── _agent/
    ├── context/       ← current-context.md and task bundles
    ├── memory/
    │   ├── working/   ← transient, time-boxed
    │   ├── episodic/  ← what happened, when
    │   └── semantic/  ← durable facts/patterns (operator-preferences.md)
    ├── sessions/      ← YYYY-MM-DD-HHMM-<slug>.md
    ├── templates/     ← canonical note templates
    ├── outputs/       ← briefs / drafts / summaries / synthesis
    ├── skills/        ← active / archived
    └── heartbeat/
 ```
 **Slug rules:** kebab-case, ASCII only, truncate to ~40 chars.
 ---
 ## Canonical Frontmatter
 Every note starts with this block. Fill what applies; leave the rest empty rather than guessing.
 ```yaml
 ---
 type:            # see Note Types below
 status:          # active | draft | done | archived | complete
 created:         # YYYY-MM-DD (or YYYY-MM-DDTHH:mm for sessions)
 updated:         # YYYY-MM-DD
 tags: []
 agent_written: false
 source_notes: []   # plain relative paths as strings — NEVER [[wikilinks]]
 ---
 ```
 `agent_written: true` + a populated `source_notes` is the key signal separating
 agent-managed content from human-authored content. When appending with POST, do
 not rewrite frontmatter — the append goes after existing content. To change
 `updated:` or `status:`, use PATCH with `Target-Type: frontmatter`.
 > **No `[[wikilinks]]` in frontmatter.** YAML parses `[[...]]` as nested lists, so wiki
 > links there break and never render as clickable links in reading view. Put all
 > cross-references in a **`## Related`** section in the note **body** (bulleted `[[links]]`).
 > Frontmatter holds scalar/string metadata only; `source_notes` values are plain relative
 > paths, not links.
 ## Note Types
 `daily-note`, `weekly-note`, `monthly-note`, `project`, `project-update`, `area`,
 `concept`, `reference`, `person`, `meeting`, `decision`, `review`, `session-log`,
 `working-memory`, `episodic-memory`, `semantic-memory`, `context-bundle`, `skill`,
 `draft`, `inbox-item`.
 ---
 ## File-Specific Conventions
 ### operator-preferences.md (`_agent/memory/semantic/`)
 The profile analog. Headings include `Operator`, `Fact / Pattern`, `Evidence`,
 `Recommendation or Implication`, `Review Notes`. Append observed facts under the
 right heading via PATCH. "The operator" is Bryan; do not attribute Jason's design
 preferences to Bryan without evidence.
 ### projects/active/\<slug\>.md
 ```markdown
 ---
 type: project
 status: active
 created: 2026-06-02
 updated: 2026-06-02
 tags: []
 agent_written: false
 source_notes: []
 ---
 # Project Name
 ## Current status
 One paragraph, kept fresh via PATCH replace.
 ## Decisions
 - [[YYYY-MM-DD-decision-slug]] — one-line summary
 ## Open threads
 - [ ] unresolved thing
 ## Log
 - 2026-06-02: observation or update
 ## Related
 - [[areas/business/business-ops]]
 ```
 ### sessions/YYYY-MM-DD-HHMM-\<slug\>.md
 See `session-log-template.md`. Note goldbrain uses an **HHMM time component** in the
 filename (unlike a date-only convention).
 ### decisions/by-date/YYYY-MM-DD-\<slug\>.md
 ADR-style: Context → Decision → Consequences. Mirror a link into `by-project/`.
 ### people/\<name\>.md
 `type: person`. Use lowercase kebab-case for the slug (e.g. `bryan-gilliom.md`).
 ---
 ## Cross-References
 Use Obsidian wiki links freely: `[[note-name]]` or `[[folder/note]]`. The REST API
 doesn't resolve them, but Obsidian does when the operator browses the vault.
@@ -0,0 +1,5 @@
 # Copy to your local shell env or secret manager. Do not commit real secrets into the vault.
 OBSIDIAN_REST_API_URL=https://goldbrainapi.mpm.to
 OBSIDIAN_REST_API_KEY=replace-me
 OBSIDIAN_VAULT_NAME=goldbrain
 COWORK_PLUGIN_MODE=disabled
@@ -0,0 +1,192 @@
 ---
 type: reference
 status: active
 created: 2026-06-02
 updated: 2026-06-02
 tags: [agent, bootstrap, system]
 agent_written: true
 source_notes: []
 ---
 # BOOTSTRAP.md
 ## Purpose
 This is the **first file any agent reads** when operating against this vault. It does three things, in order:
 1. **Checks** that the required files and folders exist.
 2. **Generates** anything that is missing, using the templates and conventions below.
 3. **Instructs** the agent on how to use the memory system once the vault is healthy.
 Run the bootstrap check at the start of every session before following the Session Protocol in [[CLAUDE]]. The check is cheap, idempotent, and safe to repeat.
 ---
 ## 1. Preflight Check
 Verify the following exist. Treat each as `[ ]` until confirmed, then `[x]`. If a path is missing, jump to the matching entry in section 2 (Repair) before continuing.
 ### Root control docs
 - [ ] `CLAUDE.md` — operating contract and session protocol
 - [ ] `BOOTSTRAP.md` — this file
 - [ ] `STRUCTURE.md` — layout, taxonomy, frontmatter standard
 - [ ] `spinup.md` — one-time setup walkthrough
 - [ ] `index.md` — navigation hub
 - [ ] `README.md` — human-facing overview
 - [ ] `.env.example` — config template for REST/API clients
 ### Required folders
 - [ ] `inbox/` (with `captures/`, `imports/`, `processing-log/`)
 - [ ] `journal/` (with `daily/`, `weekly/`, `monthly/`, `templates/`)
 - [ ] `projects/` (with `active/`, `incubating/`, `on-hold/`, `archived/`)
 - [ ] `areas/` (with `business/`, `personal/`, `learning/`, `systems/`)
 - [ ] `resources/` (with `concepts/`, `references/`, `people/`, `meetings/`, `source-material/`)
 - [ ] `decisions/` (with `by-date/`, `by-project/`)
 - [ ] `reviews/` (with `weekly/`, `monthly/`, `quarterly/`, `annual/`)
 - [ ] `archive/` (with `notes/`, `projects/`, `imports/`)
 - [ ] `_agent/` (see agent subtree below)
 ### Required `_agent/` subtree
 - [ ] `_agent/context/` — active context bundles
 - [ ] `_agent/memory/working/` — short-lived working memory
 - [ ] `_agent/memory/episodic/` — event/session-derived memory
 - [ ] `_agent/memory/semantic/` — durable facts, patterns, preferences
 - [ ] `_agent/sessions/` — session logs
 - [ ] `_agent/templates/` — note templates
 - [ ] `_agent/heartbeat/` — liveness / scheduled-run markers
 - [ ] `_agent/skills/` (with `active/`, `archived/`)
 - [ ] `_agent/outputs/` (with `briefs/`, `drafts/`, `summaries/`, `synthesis/`)
 ### Required templates
 - [ ] `_agent/templates/session-log-template.md`
 - [ ] `_agent/templates/context-bundle-template.md`
 - [ ] `_agent/templates/working-memory-template.md`
 - [ ] `_agent/templates/semantic-memory-template.md`
 - [ ] `journal/templates/daily-note-template.md`
 - [ ] `journal/templates/weekly-review-template.md`
 - [ ] `projects/project-template.md`
 - [ ] `decisions/decision-template.md`
 ### Anchor notes (recommended, not blocking)
 - [ ] `_agent/context/current-context.md`
 - [ ] `_agent/memory/semantic/operator-preferences.md`
 - [ ] today's daily note in `journal/daily/YYYY-MM-DD.md`
 A quick way to list the tree for comparison:
 ```bash
 find . -type d | sort        # folders
 find . -type f -name '*.md' | sort   # notes
 ```
 ---
 ## 2. Repair (generate what's missing)
 Only create what is missing. **Never overwrite an existing file** during bootstrap — that violates the additive-update principle in [[CLAUDE]]. If a file exists but looks malformed, flag it in the session log instead of replacing it.
 ### Missing folders
 Create the folder and add a one-line `README.md` inside any leaf folder that would otherwise be empty (Obsidian and git both ignore empty dirs):
 ```bash
 mkdir -p "<path>"
 ```
 ### Missing root control docs
 - `STRUCTURE.md`, `spinup.md`, `README.md`, `.env.example` — if absent, note it and reconstruct from the conventions in this file and [[STRUCTURE]]. Do not invent secrets in `.env.example`; use placeholders only.
 - `index.md` — rebuild as a link hub pointing at the Start Here docs, current daily note, active context, latest session log, and active projects.
 ### Missing templates
 Recreate from the canonical frontmatter (section 4). Each template is just frontmatter plus the section headings its note type uses.
 ### Missing anchor notes
 - `_agent/context/current-context.md` — create an empty context bundle (type `context-bundle`) scoped to the current task.
 - today's daily note — create from `journal/templates/daily-note-template.md`.
 - `operator-preferences.md` — only create if you have evidence to record; do not fabricate preferences.
 ### After repair
 Append a line to the daily note's **Agent Log** and write/refresh a session log in `_agent/sessions/` recording what was generated.
 ---
 ## 3. How to Use the Memory System
 Once preflight passes, operate as follows.
 ### Session start
 1. Read this file (bootstrap), then [[CLAUDE]].
 2. Read today's daily note in `journal/daily/`.
 3. Read the most recent log in `_agent/sessions/`.
 4. Read active bundles in `_agent/context/`.
 5. Scan `inbox/` for unprocessed material relevant to the task.
 6. Review active projects in `projects/active/` and open loops.
 ### During the session
 - Put short-lived state in `_agent/memory/working/` (expires; safe to prune).
 - Promote durable, reusable facts and patterns into `_agent/memory/semantic/`.
 - Record notable events and outcomes in `_agent/memory/episodic/`.
 - Keep task-scoped context in `_agent/context/` and refresh it as focus shifts.
 - Capture raw, unprocessed input in `inbox/captures/`; log processing in `inbox/processing-log/`.
 - Record meaningful choices as decision notes in `decisions/` (mirror by-date and by-project as needed).
 ### Session end
 1. Write or update a session log in `_agent/sessions/` (`YYYY-MM-DD-HHMM-slug.md`).
 2. Record what changed, decisions made, and what remains open.
 3. Update durable notes if the session produced lasting knowledge.
 4. Add a concise entry to the daily note's **Agent Log**.
 5. Leave the vault cleaner and more queryable than you found it.
 ### Memory model (where things live)
 - **Working** → `_agent/memory/working/` — transient, time-boxed.
 - **Episodic** → `_agent/memory/episodic/` — what happened, when.
 - **Semantic** → `_agent/memory/semantic/` — durable facts, patterns, preferences.
 - **Context bundles** → `_agent/context/` — task-focused reading lists and state.
 ### Safety rules (from [[CLAUDE]])
 - Do not fabricate facts, relationships, or prior decisions.
 - Do not mass-restructure the vault unless explicitly asked.
 - Do not delete notes unless deletion is explicitly requested and clearly safe.
 - Do not store secrets or API keys inside the vault.
 - Default to additive updates and explicit status changes.
 ---
 ## 4. Canonical Frontmatter
 Every note carries this block. Fill what applies; leave the rest empty rather than guessing.
 ```yaml
 ---
 type:            # one of the note types in STRUCTURE.md
 status:          # active | draft | done | archived
 created:         # YYYY-MM-DD
 updated:         # YYYY-MM-DD
 tags: []
 agent_written: false
 source_notes: []   # plain relative paths as strings — NEVER [[wikilinks]]
 ---
 ```
 Agent-generated notes set `agent_written: true` and list their `source_notes`. This is the key signal that separates agent-managed content from human-authored content.
 > **No `[[wikilinks]]` in frontmatter.** YAML interprets `[[...]]` as nested lists, so wiki
 > links in frontmatter break — they do not render as clickable links in Obsidian's reading
 > view. Put every cross-reference in a **`## Related`** section in the note **body** as a
 > bulleted list of `[[links]]`. Frontmatter holds scalar/string metadata only; `source_notes`
 > values are plain relative paths, not links. (The older `related:` frontmatter field has
 > been retired for this reason.)
 ---
 ## 5. REST / API Readiness
 Future clients (Obsidian Local REST API, CoWork plugin) may operate without filesystem access. Keep the bootstrap contract portable: stable paths, parseable frontmatter, durable titles, and all state stored in notes rather than hidden conversation memory. Config for those clients lives in a local `.env` derived from `.env.example` — never committed with real values.
 ---
 _This file is the entry point. If you change folder conventions or required files, update both this manifest and [[STRUCTURE]] so they stay in sync._
 ## Related
 - [[CLAUDE]]
 - [[STRUCTURE]]
 - [[index]]
 - [[spinup]]
@@ -0,0 +1,50 @@
 # CLAUDE.md
 ## Purpose
 This vault is a shared memory substrate for human work, Claude Code sessions, and future agent clients that access the vault through the Obsidian Local REST API or a CoWork plugin integration. The vault must remain readable by humans, writable by agents, and structured enough that tools can reliably navigate, synthesize, and update knowledge over time.
 ## Core Principles
 - Treat the vault as the system of record for long-term memory, not as a scratchpad.
 - Prefer Markdown, YAML frontmatter, wiki-links, and stable folder conventions over proprietary structures.
 - Write notes so both humans and agents can understand them without hidden context.
 - Preserve history instead of silently overwriting important decisions, summaries, or inferred preferences.
 - Keep agent-managed content clearly separated from human-authored content when possible.
 - Default to additive updates, explicit status changes, and traceable summaries.
 - Optimize for portability so the same vault can work with Claude Code, CoWork, MCP-compatible tools, REST API clients, and future agents.
 ## What This Agent Is
 You are an agent operating against an Obsidian vault that functions as an AI second brain. Your role is to read context, synthesize across notes, create structured outputs, update memory carefully, and leave durable traces of work in the vault rather than keeping important state inside the conversation only.
 ## Bootstrap (Start Here)
 Before anything else in a new session, read [[BOOTSTRAP]] (`BOOTSTRAP.md`). It is the entry point to the memory system: it verifies that the required files and folders exist, regenerates anything missing using the canonical conventions, and restates how to operate the vault. Only proceed to the Session Protocol below once the bootstrap preflight passes. Never overwrite existing files during bootstrap — generate only what is missing.
 ## Session Protocol
 At the start of each session:
 0. Run the bootstrap preflight in [[BOOTSTRAP]] and repair any missing files/folders.
 1. Read today’s daily note in `journal/daily/` if present.
 2. Read the most recent relevant notes in `_agent/sessions/`.
 3. Read active context files in `_agent/context/`.
 4. Check `inbox/` for unprocessed material related to the task.
 5. Review active project notes and open loops before taking action.
 At the end of each session:
 1. Write or update a session log in `_agent/sessions/`.
 2. Record what changed, what decisions were made, and what remains open.
 3. Update related notes if the session produced durable knowledge.
 4. Add a concise agent log block to the daily note when appropriate.
 5. Leave the vault in a cleaner, more queryable state than it was at the start.
 ## Memory Model
 - Working memory: `_agent/memory/working/`
 - Episodic memory: `_agent/memory/episodic/`
 - Semantic memory: `_agent/memory/semantic/`
 - Task-focused context bundles: `_agent/context/`
 ## REST/API Readiness
 Assume future clients may interact through the Obsidian Local REST API instead of direct filesystem access. Keep paths predictable, frontmatter parseable, titles stable, and state stored in notes rather than hidden memory.
 ## Safety
 - Do not fabricate facts, relationships, or prior decisions.
 - Do not mass-restructure the vault unless explicitly asked.
 - Do not delete notes unless deletion is explicitly requested and clearly safe.
 - Do not store secrets or API keys inside the vault.
@@ -0,0 +1,20 @@
 # Starter Memory Vault
 This is a review scaffold for an Obsidian-based memory vault designed for Claude Code, future CoWork plugin integration, and Obsidian Local REST API access.
 ## Included
 - Root control docs: `CLAUDE.md`, `STRUCTURE.md`, `BOOTSTRAP.md`, `spinup.md`
 - Core knowledge folders
 - Agent memory and session folders
 - Starter templates
 - Starter seed notes
 - Index pages for navigation
 - `.env.example` for future local integration config
 ## Review focus
 - Folder shape
 - Frontmatter standards
 - Note taxonomy
 - Session flow
 - Agent memory layout
 - CoWork/API readiness
@@ -0,0 +1,66 @@
 # STRUCTURE.md
 ## Purpose
 This document defines the vault layout, note taxonomy, naming conventions, and frontmatter templates for a memory storage vault designed for Claude Code today and future CoWork plugin access through the Obsidian Local REST API.
 ## Recommended Vault Layout
 ```text
 vault/
 ├── CLAUDE.md
 ├── STRUCTURE.md
 ├── BOOTSTRAP.md
 ├── spinup.md
 ├── index.md
 ├── README.md
 ├── inbox/
 ├── journal/
 ├── projects/
 ├── areas/
 ├── resources/
 ├── decisions/
 ├── reviews/
 ├── _agent/
 └── archive/
 ```
 ## Note Types
 - daily-note
 - weekly-note
 - monthly-note
 - project
 - project-update
 - area
 - concept
 - reference
 - person
 - meeting
 - decision
 - review
 - session-log
 - working-memory
 - episodic-memory
 - semantic-memory
 - context-bundle
 - skill
 - draft
 - inbox-item
 ## Core Frontmatter
 ```yaml
 ---
 type:
 status:
 created:
 updated:
 tags: []
 agent_written: false
 source_notes: []   # plain relative paths as strings — NEVER [[wikilinks]]
 ---
 ```
 > **No `[[wikilinks]]` in frontmatter.** YAML parses `[[...]]` as nested lists, so wiki
 > links placed in frontmatter (e.g. an old `related:` field) silently break and do not
 > render as clickable links. All cross-references go in a **`## Related`** section in the
 > note **body**, as a bulleted list of `[[links]]`. Keep frontmatter to scalar/string
 > metadata only. `source_notes`, when used, holds plain relative path strings, not links.
@@ -0,0 +1,45 @@
 ---
 type: context-bundle
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [agent, context]
 agent_written: true
 source_notes: []
 scope: vault-foundation
 refresh_strategy: on-demand
 ---
 # Current Context
 ## Scope
 Initial scaffold review for a Claude Code + Obsidian memory vault.
 ## Active Priorities
 - Review scaffold folders.
 - Review templates.
 - Review root docs.
 - Plan REST API and CoWork plugin alignment.
 ## Relevant Entities
 - [[projects/active/vault-foundation]]
 - [[resources/references/obsidian-local-rest-api]]
 - [[resources/people/jason-stedwell]]
 ## Key Decisions
 - Separate durable knowledge from operational agent state.
 - Preserve portability across direct filesystem and API-driven clients.
 ## Open Questions
 - Which note types should the plugin create directly?
 - Should decisions live by project only, or by date and project?
 - What should the session end hook write automatically?
 ## Source Notes
 - [[journal/daily/2026-06-01]]
 - [[projects/active/vault-foundation]]
 ## Related
 - [[projects/active/vault-foundation]]
 - [[journal/daily/2026-06-01]]
 - [[_agent/sessions/2026-06-01-2200-initial-vault-scaffold]]
@@ -0,0 +1,3 @@
 # Heartbeat
 Use this folder for periodic state snapshots, compression summaries, and maintenance reports.
@@ -0,0 +1,5 @@
 # episodic/
 Episodic memory: notable events and outcomes, what happened and when.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,34 @@
 ---
 type: semantic-memory
 status: active
 created: 2026-06-01
 updated: 2026-06-02
 tags: [agent, semantic-memory, preferences]
 agent_written: true
 source_notes: []
 confidence: medium
 last_reviewed: 2026-06-02
 ---
 # Operator Preferences
 ## Operator
 The **primary operator** of this vault is [[resources/people/bryan-gilliom]] (Bryan Gilliom, CEO of Message Point Media). Unless stated otherwise, "the operator" below refers to Bryan. [[resources/people/jason-stedwell]] is the vault's architect/creator and a possible future collaborator; preferences attributed to the vault's design originate with Jason and should not be assumed to be Bryan's until observed.
 ## Fact / Pattern
 The vault is built around structured systems, clear roadmaps, durable documentation, and implementation-ready scaffolds. Bryan's own working preferences are not yet established and should be captured from real interactions rather than assumed.
 ## Evidence
 The vault's design and request history (root documentation, structural guidance, setup walkthroughs, plugin-oriented direction) reflect Jason's design intent as architect. No direct evidence of Bryan's preferences has been recorded yet.
 ## Recommendation or Implication
 Default to explicit files, repeatable workflows, and low-ambiguity structure when extending this vault. As Bryan uses the system, record observed preferences here with evidence and raise confidence accordingly — do not fabricate.
 ## Review Notes
 Reconfirm and attribute preferences to Bryan once direct interactions provide evidence; revisit at the start of the plugin development workflow.
 ## Related
 - [[CLAUDE]]
 - [[resources/people/bryan-gilliom]]
 - [[resources/people/jason-stedwell]]
 - [[projects/active/vault-foundation]]
@@ -0,0 +1,30 @@
 ---
 type: working-memory
 status: active
 created: 2026-06-01T22:00
 updated: 2026-06-01T22:00
 tags: [agent, working-memory]
 agent_written: true
 source_notes: []
 expires_after: 48h
 ---
 # Working Context
 ## Active Focus
 Starter scaffold review and refinement.
 ## Recent Decisions
 - Include root navigation notes.
 - Include config example for future REST/API use.
 ## Open Threads
 - Add hooks, policies, and plugin CRUD docs.
 ## Relevant Links
 - [[index]]
 - [[README]]
 ## Related
 - [[_agent/context/current-context]]
 - [[projects/active/vault-foundation]]
@@ -0,0 +1,5 @@
 # briefs/
 Agent-generated briefs.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # drafts/
 Agent-generated drafts.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # summaries/
 Agent-generated summaries.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # synthesis/
 Agent-generated synthesis across notes.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,53 @@
 ---
 type: session-log
 status: complete
 created: 2026-06-01T22:00
 updated: 2026-06-01T22:00
 tags: [agent, session, scaffold]
 agent_written: true
 source_notes: []
 session_date: 2026-06-01
 client: claude-code
 ---
 # Session Log
 ## Goal
 Create a reviewable starter scaffold for a memory-oriented Obsidian vault.
 ## Notes Read
 - [[CLAUDE]]
 - [[STRUCTURE]]
 - [[BOOTSTRAP]]
 - [[spinup]]
 ## Actions Taken
 - Created the core folder tree.
 - Added root operating documents.
 - Added templates for high-value note types.
 - Seeded example operational notes.
 - Added API config example and review index.
 ## Decisions Made
 - Include `_agent/` as a first-class operational layer.
 - Add a root `index.md` and `README.md` for review and navigation.
 - Include `.env.example` but not actual config.
 ## Outputs Created
 - Starter vault scaffold
 - Root docs
 - Templates
 - Seed notes
 ## Open Threads
 - Add plugin integration spec.
 - Add startup/shutdown hooks.
 - Add archive policy and sync policy notes.
 ## Suggested Next Step
 Review the scaffold and then generate a plugin spec plus note CRUD contract.
 ## Related
 - [[projects/active/vault-foundation]]
 - [[_agent/context/current-context]]
 - [[journal/daily/2026-06-01]]
@@ -0,0 +1,58 @@
 ---
 type: session-log
 status: complete
 created: 2026-06-02T16:18
 updated: 2026-06-02T16:18
 tags: [agent, session, plugin, rest-api, goldbrain]
 agent_written: true
 source_notes: ["resources/references/obsidian-local-rest-api.md", "references-only/reference-obsidian-memory.plugin"]
 session_date: 2026-06-02
 client: cowork
 ---
 # Session Log
 ## Goal
 Prep the goldbrain vault from the reference materials, stand up and verify the Obsidian Local REST API, and build the `goldbrain-memory` CoWork plugin ready to hand off to Bryan.
 ## Notes Read
 - [[BOOTSTRAP]], [[STRUCTURE]], [[CLAUDE]], [[spinup]]
 - [[_agent/memory/semantic/operator-preferences]], [[resources/people/bryan-gilliom]]
 - [[resources/references/obsidian-local-rest-api]]
 ## Actions Taken
 Reviewed the references-only materials (reference vault + the existing `obsidian-memory` plugin + REST API docs). Found the vault scaffold was structurally complete but plugin/REST-readiness was thin, so filled the stub API reference with a full command reference + memory routing map and refreshed `.env.example` for goldbrain.
 Diagnosed a `502` from the reverse proxy: the Obsidian Local REST API plugin was bound to `127.0.0.1`. Changed binding to `0.0.0.0` and added the proxy hostname to the cert SAN; API came up clean (v4.1.2, valid TLS). Verified a full write → read → list → delete round-trip.
 Confirmed the scaffold copy into the live vault, then created the 24 empty subfolders that file-copy had dropped (placeholder READMEs) so the full required tree resolves over the API. Marked spin-up steps complete.
 Built the `goldbrain-memory` plugin (skill + 4 reference files) adapted to: operator = Bryan, base URL `goldbrainapi.mpm.to`, vault-root paths, goldbrain's PARA + `_agent/` layout, canonical frontmatter, HHMM session logs. Live-tested every documented operation.
 Fixed two bugs found during testing: (1) v4.1.2 PATCH requires the **full `::`-delimited heading path** (bare subheading name returns `invalid-target`); (2) `[[wikilinks]]` in YAML frontmatter break in Obsidian's reading view — migrated all 23 affected notes to move links into a body `## Related` section, retired the `related:` frontmatter field, and codified the rule in STRUCTURE.md / BOOTSTRAP.md and the plugin docs.
 ## Decisions Made
 - Vault addressed at root (no `Projects/agents/` prefix) — goldbrain is a dedicated vault.
 - API base URL `https://goldbrainapi.mpm.to`; no `-k` needed (valid cert behind reverse proxy → `192.168.86.15:27124`).
 - API key hardcoded in the plugin only, never written into the vault (per the vault's own safety rule).
 - Rule established: no `[[wikilinks]]` in frontmatter; all cross-references live in a body `## Related` section. `source_notes` holds plain relative path strings.
 - PATCH heading targets must use the full `H1::H2` path.
 ## Outputs Created
 - `goldbrain-memory.plugin` — installable CoWork plugin (delivered to the goldbrain root folder)
 - Full REST command reference + routing map in [[resources/references/obsidian-local-rest-api]]
 - 24 folder-placeholder READMEs; 23 notes + templates migrated for the frontmatter-link fix
 ## Open Threads
 - [ ] Validate Claude Code direct filesystem access to the vault host (spin-up step 6).
 - [ ] Capture Bryan's real preferences in [[_agent/memory/semantic/operator-preferences]] from actual use — do not fabricate.
 - [ ] Begin the daily/session/review operating rhythm (spin-up step 8).
 ## Suggested Next Step
 Hand off `goldbrain-memory.plugin` to Bryan, install it, and run one live session to confirm the skill triggers and that load/write land correctly through the plugin.
 ## Related
 - [[projects/active/vault-foundation]]
 - [[resources/references/obsidian-local-rest-api]]
 - [[resources/people/bryan-gilliom]]
 - [[BOOTSTRAP]]
@@ -0,0 +1,3 @@
 # Active Skills
 Store reusable agent skills here with clear triggers, versioning, and expected outputs.
@@ -0,0 +1,5 @@
 # archived/
 Retired agent skills.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,27 @@
 ---
 type: context-bundle
 status: active
 created: {{date:YYYY-MM-DD}}
 updated: {{date:YYYY-MM-DD}}
 tags: [agent, context]
 agent_written: true
 source_notes: []
 scope:
 refresh_strategy: on-demand
 ---
 # Context Bundle Title
 ## Scope
 ## Active Priorities
 ## Relevant Entities
 ## Key Decisions
 ## Open Questions
 ## Source Notes
 ## Related
@@ -0,0 +1,23 @@
 ---
 type: semantic-memory
 status: active
 created: {{date:YYYY-MM-DD}}
 updated: {{date:YYYY-MM-DD}}
 tags: [agent, semantic-memory]
 agent_written: true
 source_notes: []
 confidence: high
 last_reviewed: {{date:YYYY-MM-DD}}
 ---
 # Semantic Memory Title
 ## Fact / Pattern
 ## Evidence
 ## Recommendation or Implication
 ## Review Notes
 ## Related
@@ -0,0 +1,29 @@
 ---
 type: session-log
 status: complete
 created: {{date:YYYY-MM-DDTHH:mm}}
 updated: {{date:YYYY-MM-DDTHH:mm}}
 tags: [agent, session]
 agent_written: true
 source_notes: []
 session_date: {{date:YYYY-MM-DD}}
 client: claude-code
 ---
 # Session Log
 ## Goal
 ## Notes Read
 ## Actions Taken
 ## Decisions Made
 ## Outputs Created
 ## Open Threads
 ## Suggested Next Step
 ## Related
@@ -0,0 +1,22 @@
 ---
 type: working-memory
 status: active
 created: {{date:YYYY-MM-DDTHH:mm}}
 updated: {{date:YYYY-MM-DDTHH:mm}}
 tags: [agent, working-memory]
 agent_written: true
 source_notes: []
 expires_after: 48h
 ---
 # Working Context
 ## Active Focus
 ## Recent Decisions
 ## Open Threads
 ## Relevant Links
 ## Related
@@ -0,0 +1,3 @@
 # Archive
 Move completed or inactive notes here instead of deleting them when they may still be useful later.
@@ -0,0 +1,5 @@
 # imports/
 Archived imported material.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # notes/
 Archived standalone notes.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # projects/
 Archived project material.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,22 @@
 ---
 type: area
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [area, business]
 agent_written: false
 source_notes: []
 ---
 # Business Ops
 ## Scope
 Operational business responsibilities that persist beyond any single project.
 ## Active Concerns
 - Documentation systems
 - Client operations
 - Tooling standardization
 ## Related
 - [[projects/active/vault-foundation]]
@@ -0,0 +1,22 @@
 ---
 type: area
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [area, learning]
 agent_written: false
 source_notes: []
 ---
 # Learning Backlog
 ## Scope
 Topics worth exploring and formalizing into durable notes.
 ## Current Topics
 - Obsidian Local REST API details
 - CoWork plugin design patterns
 - Session compression into semantic memory
 ## Related
 - [[resources/references/obsidian-local-rest-api]]
@@ -0,0 +1,5 @@
 # personal/
 Ongoing personal responsibilities and notes.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,23 @@
 ---
 type: area
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [area, systems]
 agent_written: false
 source_notes: []
 ---
 # Systems Architecture
 ## Scope
 System-level design decisions, infrastructure patterns, and integration planning.
 ## Active Concerns
 - Vault architecture
 - API integration patterns
 - Plugin interoperability
 ## Related
 - [[projects/active/vault-foundation]]
 - [[resources/references/obsidian-local-rest-api]]
@@ -0,0 +1,5 @@
 # by-date/
 Decision records indexed chronologically.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # by-project/
 Decision records mirrored by project.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,25 @@
 ---
 type: decision
 status: complete
 created: {{date:YYYY-MM-DD}}
 updated: {{date:YYYY-MM-DD}}
 tags: [decision]
 agent_written: true
 source_notes: []
 decision_date: {{date:YYYY-MM-DD}}
 impact: medium
 ---
 # Decision Title
 ## Context
 ## Decision
 ## Rationale
 ## Consequences
 ## Follow-Up
 ## Related
@@ -0,0 +1,3 @@
 # Inbox Captures
 Drop raw captures here before they are processed into canonical notes.
@@ -0,0 +1,5 @@
 # imports/
 Raw imported material awaiting processing.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # processing-log/
 Logs of how inbox items were triaged and where they went.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,28 @@
 # Vault Index
 ## Start Here
 - [[README]]
 - [[CLAUDE]]
 - [[STRUCTURE]]
 - [[BOOTSTRAP]]
 - [[spinup]]
 ## Operational Notes
 - [[journal/daily/2026-06-01]]
 - [[_agent/context/current-context]]
 - [[_agent/sessions/2026-06-01-2200-initial-vault-scaffold]]
 - [[projects/active/vault-foundation]]
 ## Core Areas
 - [[areas/business/business-ops]]
 - [[areas/systems/systems-architecture]]
 - [[areas/learning/learning-backlog]]
 ## Reference Notes
 - [[resources/concepts/agent-memory-model]]
 - [[resources/references/obsidian-local-rest-api]]
 - [[resources/people/bryan-gilliom]]
 - [[resources/people/jason-stedwell]]
 ## Reviews
 - [[reviews/weekly/2026-W23]]
@@ -0,0 +1,37 @@
 ---
 type: daily-note
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [daily, journal]
 agent_written: false
 source_notes: []
 ---
 # 2026-06-01
 ## Top Priorities
 - Review and refine starter memory vault scaffold.
 - Finalize note taxonomy and folder layout.
 - Prepare for future Obsidian REST API and CoWork plugin work.
 ## Schedule / Commitments
 - Initial vault design and scaffold review.
 ## Open Loops
 - Decide whether to keep `areas/` broad or business-specific.
 - Decide which templates should be exposed in the plugin UI first.
 - Decide how session compression should roll into semantic memory.
 ## Notes
 This vault is being initialized as a human-plus-agent memory system.
 ## Context for AI
 Prioritize stable structure, machine-readable metadata, and low-friction future API access.
 ## Agent Log
 - Initial scaffold generated for review.
 ## Related
 - [[projects/active/vault-foundation]]
 - [[_agent/context/current-context]]
@@ -0,0 +1,27 @@
 ---
 type: daily-note
 status: active
 created: 2026-06-02
 updated: 2026-06-02
 tags: [daily, journal]
 agent_written: false
 source_notes: []
 ---
 # 2026-06-02
 ## Top Priorities
 ## Schedule / Commitments
 ## Open Loops
 ## Notes
 ## Context for AI
 ## Agent Log
 - 16:18 — Built and verified the goldbrain-memory plugin; see [[_agent/sessions/2026-06-02-1618-goldbrain-plugin-build]].
 ## Related
@@ -0,0 +1,5 @@
 # monthly/
 Monthly journal notes.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,25 @@
 ---
 type: daily-note
 status: active
 created: {{date:YYYY-MM-DD}}
 updated: {{date:YYYY-MM-DD}}
 tags: [daily, journal]
 agent_written: false
 source_notes: []
 ---
 # {{date:YYYY-MM-DD}}
 ## Top Priorities
 ## Schedule / Commitments
 ## Open Loops
 ## Notes
 ## Context for AI
 ## Agent Log
 ## Related
@@ -0,0 +1,26 @@
 ---
 type: review
 status: active
 created: {{date:gggg-[W]WW}}
 updated: {{date:gggg-[W]WW}}
 tags: [review, weekly]
 agent_written: true
 source_notes: []
 period: weekly
 ---
 # Weekly Review
 ## Completed Work
 ## Open Loops
 ## Stale Projects
 ## Decisions
 ## Priorities Next Week
 ## Agent Notes
 ## Related
@@ -0,0 +1,5 @@
 # weekly/
 Weekly journal notes.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,54 @@
 ---
 type: project
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [project, vault]
 agent_written: false
 source_notes: []
 owner: Jason Stedwell
 review_cycle: weekly
 ---
 # Vault Foundation
 ## Purpose
 Build an Obsidian memory vault scaffold that supports Claude Code now and future CoWork plugin access later.
 ## Status
 Scaffold created and ready for review.
 ## Goals
 - Create clean root docs.
 - Establish predictable folder structure.
 - Define frontmatter and note taxonomy.
 - Seed initial notes and templates.
 - Prepare for REST API integration.
 ## Current Context
 This project is the setup layer for the broader memory vault system.
 ## Open Loops
 - Finalize plugin-facing CRUD conventions.
 - Decide how reviews should promote working memory into semantic memory.
 - Determine whether to add dashboards or MOC notes in v1.
 ## Key Decisions
 - Separate `_agent/` from human-facing knowledge folders.
 - Use frontmatter-based note typing.
 - Keep secrets outside the vault.
 ## Related Notes
 - [[index]]
 - [[BOOTSTRAP]]
 - [[spinup]]
 - [[resources/concepts/agent-memory-model]]
 ## Session History
 - [[_agent/sessions/2026-06-01-2200-initial-vault-scaffold]]
 ## Related
 - [[CLAUDE]]
 - [[STRUCTURE]]
 - [[_agent/context/current-context]]
 - [[journal/daily/2026-06-01]]
@@ -0,0 +1,5 @@
 # archived/
 Completed or abandoned projects.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # incubating/
 Early-stage project ideas not yet active.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # on-hold/
 Paused projects, kept for later resumption.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,31 @@
 ---
 type: project
 status: active
 created: {{date:YYYY-MM-DD}}
 updated: {{date:YYYY-MM-DD}}
 tags: [project]
 agent_written: false
 source_notes: []
 owner:
 review_cycle: weekly
 ---
 # Project Name
 ## Purpose
 ## Status
 ## Goals
 ## Current Context
 ## Open Loops
 ## Key Decisions
 ## Related Notes
 ## Session History
 ## Related
@@ -0,0 +1,32 @@
 ---
 type: concept
 status: reference
 created: 2026-06-01
 updated: 2026-06-01
 tags: [concept, memory, agent]
 agent_written: false
 source_notes: []
 ---
 # Agent Memory Model
 ## Summary
 This vault uses a layered memory design with working memory, episodic memory, semantic memory, and task-focused context bundles.
 ## Key Details
 - Working memory supports active session execution.
 - Episodic memory preserves what happened.
 - Semantic memory stores stable patterns and durable knowledge.
 - Context bundles provide compact, high-value retrieval targets.
 ## Why It Matters
 This separation reduces clutter and makes future API-driven retrieval more efficient.
 ## Related Concepts
 - [[resources/references/obsidian-local-rest-api]]
 - [[projects/active/vault-foundation]]
 ## Related
 - [[CLAUDE]]
 - [[_agent/context/current-context]]
 - [[_agent/memory/semantic/operator-preferences]]
@@ -0,0 +1,5 @@
 # meetings/
 Meeting notes and records.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,42 @@
 ---
 type: person
 status: active
 created: 2026-06-02
 updated: 2026-06-02
 tags: [person, primary-operator]
 agent_written: true
 source_notes: []
 company: Message Point Media (MPM)
 role: CEO
 last_contact:
 ---
 # Bryan Gilliom
 ## Who They Are
 CEO of Message Point Media (MPM) and the **primary user** of this memory vault. This vault exists to serve as Bryan's persistent second brain across Claude/CoWork sessions — the system of record for his context, decisions, projects, and preferences.
 ## Relationship Context
 - **Primary operator** — default "the operator" in agent memory and preferences refers to Bryan unless stated otherwise.
 - [[resources/people/jason-stedwell]] is the architect and creator of the vault, and a possible future collaborator — not the day-to-day user.
 ## Working Preferences
 _To be learned and recorded as evidence accumulates. Do not fabricate — capture only what is observed or stated, then promote durable patterns to [[_agent/memory/semantic/operator-preferences]]._
 ## Recent Interactions
 - _None recorded yet._
 ## Open Follow-Ups
 - Confirm Bryan's preferred communication style, output formats, and recurring workflows.
 - Identify the active projects and areas Bryan wants tracked first.
 - Confirm which connectors/tools Bryan relies on (MPM systems, email, calendar, etc.).
 ## Related
 - [[resources/people/jason-stedwell]]
 - [[_agent/memory/semantic/operator-preferences]]
@@ -0,0 +1,38 @@
 ---
 type: person
 status: active
 created: 2026-06-01
 updated: 2026-06-01
 tags: [person]
 agent_written: false
 source_notes: []
 company: MPM / ALABAMA wISP
 role: Director of Technical Services / Systems Engineer
 last_contact: 2026-06-01
 ---
 # Jason Stedwell
 ## Who They Are
 Primary designer of this memory vault system.
 ## Relationship Context
 Designed the structure, workflow, and future plugin direction for this vault.
 ## Recent Interactions
 - Requested starter vault scaffold and documentation-first setup.
 ## Open Follow-Ups
 - Confirm plugin CRUD priorities.
 - Confirm desired startup/shutdown agent hooks.
 ## Related Projects
 - [[projects/active/vault-foundation]]
 ## Related
 - [[projects/active/vault-foundation]]
@@ -0,0 +1,245 @@
 ---
 type: reference
 status: active
 created: 2026-06-01
 updated: 2026-06-02
 tags: [reference, api, obsidian, rest, plugin]
 agent_written: true
 source_notes: []
 ---
 # Obsidian Local REST API
 ## Summary
 This is the operational command reference for reaching the **goldbrain** vault over the
 [Obsidian Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api).
 It is the contract a CoWork plugin or any REST client follows to read and write memory.
 Paths address the vault **at its root** (e.g. `/vault/_agent/...`), matching the layout
 defined in STRUCTURE and verified by BOOTSTRAP.
 ## Connection
 | Setting | Value |
 |---------|-------|
 | Base URL | `https://goldbrainapi.mpm.to` |
 | Auth | `Authorization: Bearer <key>` on every request |
 | Content type (writes) | `text/markdown` (or `application/json` for frontmatter patches) |
 **Never store the key in the vault.** It lives in the local environment / plugin config,
 not in any note. The examples below read it from the shell:
 ```bash
 export OBSIDIAN_REST_API_URL="https://goldbrainapi.mpm.to"
 export OBSIDIAN_REST_API_KEY="<bearer-token>"
 AUTH="Authorization: Bearer ${OBSIDIAN_REST_API_KEY}"
 BASE="${OBSIDIAN_REST_API_URL}"
 ```
 > TLS note: `goldbrainapi.mpm.to` presents a valid certificate (reverse proxy →
 > `192.168.86.15:27124`), so `-k` is **not** needed. Add `-k` only if the endpoint is ever
 > switched to a self-signed certificate.
 ---
 ## Reading Files
 ```bash
 curl -s -H "$AUTH" "$BASE/vault/_agent/context/current-context.md"
 ```
 Returns raw file content (`text/markdown`). A `404` means the file does not exist.
 ```bash
 # Read only one heading's content (full heading path, :: delimited)
 curl -s -H "$AUTH" \
  "$BASE/vault/_agent/memory/semantic/operator-preferences.md/heading/Operator%20Preferences%3A%3AFact%20%2F%20Pattern"
 ```
 ---
 ## Listing Directories
 ```bash
 curl -s -H "$AUTH" "$BASE/vault/_agent/sessions/"   # trailing slash required
 ```
 Returns JSON: `{ "files": [...], "folders": [...] }`.
 ---
 ## Appending Content (POST)
 `POST` appends to the **end** of an existing file; it creates the file if absent.
 ```bash
 cat > /tmp/obs_entry.md << 'OBSEOF'
 - 2026-06-02: quick note to triage later
 OBSEOF
 curl -s -X POST -H "$AUTH" -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_entry.md \
  "$BASE/vault/inbox/captures/inbox.md"
 ```
 ---
 ## Creating or Overwriting Files (PUT)
 `PUT` creates a new file or fully overwrites one. Missing parent directories are created automatically.
 ```bash
 cat > /tmp/obs_file.md << 'OBSEOF'
 ---
 type: session-log
 status: complete
 created: 2026-06-02
 updated: 2026-06-02
 tags: []
 agent_written: true
 source_notes: []
 ---
 # Session: <title>
 ## Related
 - [[projects/active/some-project]]
 OBSEOF
 curl -s -X PUT -H "$AUTH" -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_file.md \
  "$BASE/vault/_agent/sessions/2026-06-02-1430-my-session.md"
 ```
 Include the canonical frontmatter (see STRUCTURE / BOOTSTRAP §4) and set `agent_written: true`
 on agent-generated notes. Cross-reference links go in a body `## Related` section, never in frontmatter.
 ---
 ## Patching a Specific Section (PATCH)
 `PATCH` edits inside a file without rewriting it. Target and operation are set via headers.
 ### Append under a heading
 **Heading targets must be the FULL heading path, `::`-delimited from the top-level heading.**
 A bare subheading name returns `400 invalid-target` (errorCode 40080). Verified against
 API v4.1.2. Example: `## Fact / Pattern` under `# Operator Preferences` →
 `Target: Operator Preferences::Fact / Pattern`. Percent-encode non-ASCII; spaces are fine.
 ```bash
 cat > /tmp/obs_patch.md << 'OBSEOF'
 Bryan prefers concise status updates — lead with the decision.
 OBSEOF
 curl -s -X PATCH -H "$AUTH" \
  -H "Operation: append" \
  -H "Target-Type: heading" \
  -H "Target: Operator Preferences::Fact / Pattern" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/obs_patch.md \
  "$BASE/vault/_agent/memory/semantic/operator-preferences.md"
 ```
 To discover exact heading paths, GET the note with `Accept: application/vnd.olrapi.document-map+json`;
 it returns `{ "headings": [...], "blocks": [...], "frontmatterFields": [...] }` — copy the
 heading string verbatim into `Target`.
 ### Replace a heading's content entirely
 Same call with `Operation: replace` — e.g. to refresh a project's `Project Name::Current status`.
 ### Prepend under a heading
 Same call with `Operation: prepend`.
 ### Patch a frontmatter field
 ```bash
 curl -s -X PATCH -H "$AUTH" \
  -H "Operation: replace" \
  -H "Target-Type: frontmatter" \
  -H "Target: updated" \
  -H "Content-Type: application/json" \
  --data '"2026-06-02"' \
  "$BASE/vault/projects/active/vault-foundation.md"
 ```
 Use this to keep `updated:` and `status:` current after a write.
 ---
 ## Searching
 ```bash
 curl -s -X POST -H "$AUTH" "$BASE/search/simple/?query=weekly+review"
 ```
 Returns an array of `{ filename, score, matches: [{ context, match }] }`.
 ---
 ## Deleting Files
 ```bash
 curl -s -X DELETE -H "$AUTH" "$BASE/vault/archive/notes/old-note.md"
 ```
 Only on an explicit request. Deletion is destructive; memory is append-friendly.
 ---
 ## URL-Encoding Notes
 - Path separators (`/`) in the vault path are **literal** — do not encode them.
 - Spaces in filenames or heading targets in a URL: use `%20`.
 - Nested heading levels in a URL path: use `%3A%3A` for `::`.
 - Heading text in the `Target:` header: the **full heading path** joined by `::` (e.g. `Operator Preferences::Fact / Pattern`), no `#`; spaces fine; percent-encode non-ASCII.
 ---
 ## Memory Routing Map
 Where each kind of write lands in goldbrain (mirrors BOOTSTRAP §3 and the taxonomy in STRUCTURE).
 | Situation | Vault path | Method |
 |-----------|-----------|--------|
 | Unsorted / quick capture | `inbox/captures/inbox.md` (date-prefixed line) | POST |
 | Raw imported material | `inbox/imports/` | PUT |
 | Operator preference / durable fact | `_agent/memory/semantic/operator-preferences.md` | PATCH |
 | Other durable facts, patterns | `_agent/memory/semantic/<slug>.md` | PUT |
 | Event record (what happened) | `_agent/memory/episodic/<slug>.md` | PUT |
 | Short-lived, time-boxed state | `_agent/memory/working/<slug>.md` | PUT |
 | Task-scoped context / focus | `_agent/context/current-context.md` | PATCH / PUT |
 | Working-session log | `_agent/sessions/YYYY-MM-DD-HHMM-<slug>.md` | PUT |
 | Long-running project state | `projects/active/<slug>.md` | PUT + PATCH |
 | Non-obvious decision (ADR) | `decisions/by-date/YYYY-MM-DD-<slug>.md` (mirror `by-project/`) | PUT |
 | Person context | `resources/people/<name>.md` | PUT / PATCH |
 | Concept / reference note | `resources/concepts/` or `resources/references/` | PUT |
 | Daily activity / Agent Log | `journal/daily/YYYY-MM-DD.md` | POST / PATCH |
 | Periodic review | `reviews/{weekly,monthly,quarterly,annual}/` | PUT |
 **Slug rules:** kebab-case, ASCII, ~40 chars max. Every file carries canonical frontmatter (no `[[wikilinks]]` in it).
 ---
 ## Plugin Readiness Checklist
 - [ ] Base URL reachable; returns `401` without the key, content with it.
 - [ ] `GET /vault/BOOTSTRAP.md` succeeds (vault bootstrapped — else run BOOTSTRAP).
 - [ ] A test `PUT` into `_agent/sessions/` creates the file and parent dirs.
 - [ ] A `PATCH` `Target-Type: heading` append with a full `::` path lands under the right heading.
 - [ ] `POST /search/simple/?query=...` returns scored matches.
 - [ ] Key supplied via env / plugin config only — never written into a note.
 ## Sources / Notes
 Adapted from the working `obsidian-memory` plugin reference, retargeted to goldbrain's
 vault-root layout and the `goldbrainapi.mpm.to` host. Record host-binding or plugin-specific
 conventions here as they emerge.
 ## Related
 - [[spinup]]
 - [[BOOTSTRAP]]
 - [[STRUCTURE]]
 - [[CLAUDE]]
 - [[_agent/context/current-context]]
 - [[projects/active/vault-foundation]]
@@ -0,0 +1,5 @@
 # source-material/
 Raw source documents and references to process.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # annual/
 Annual reviews.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # monthly/
 Monthly reviews.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,5 @@
 # quarterly/
 Quarterly reviews.
 > Placeholder so this folder persists (empty dirs are dropped by file copies and git). Safe to delete once the folder has real content.
@@ -0,0 +1,37 @@
 ---
 type: review
 status: active
 created: 2026-W23
 updated: 2026-W23
 tags: [review, weekly]
 agent_written: true
 source_notes: []
 period: weekly
 ---
 # Weekly Review
 ## Completed Work
 - Created the starter memory vault scaffold.
 ## Open Loops
 - Review and refine all templates.
 - Add plugin-facing contracts.
 ## Stale Projects
 - None yet.
 ## Decisions
 - Root docs will define vault behavior.
 - `_agent/` will hold operational agent state.
 ## Priorities Next Week
 - Add plugin spec.
 - Add startup/shutdown automation docs.
 ## Agent Notes
 Use this note to promote important observations into semantic memory.
 ## Related
 - [[journal/daily/2026-06-01]]
 - [[projects/active/vault-foundation]]
@@ -0,0 +1,29 @@
 # spinup.md
 ## Purpose
 This guide is the complete user (not agent) spin-up walkthrough for taking a fresh Obsidian vault from empty folder to live operational memory system for Claude Code, with a path toward future CoWork plugin integration through the Obsidian Local REST API.
 ## High-Level Flow
 - [x] 1. Create the vault.
 - [x] 2. Add root operating docs.
 - [x] 3. Build the folder tree.
 - [x] 4. Add templates.
 - [x] 5. Create initial notes.
 - [ ] 6. Validate Claude Code access.
 - [x] 7. Enable the Obsidian Local REST API.
 - [ ] 8. Start the daily/session/review operating rhythm.
 ## Verified status — 2026-06-02
 Checked against the live vault at `goldbrainapi.mpm.to` after the scaffold copy.
 - **1. Create the vault** — Done. Vault is live and reachable via the REST API.
 - **2. Add root operating docs** — Done. `CLAUDE.md`, `BOOTSTRAP.md`, `STRUCTURE.md`, `spinup.md`, `index.md`, `README.md`, and `.env.example` all present.
 - **3. Build the folder tree** — Done. Full tree present and verified over the API. The empty subfolders that file-copy dropped (`inbox/imports`, `inbox/processing-log`, `journal/weekly`, `journal/monthly`, `projects/incubating`, `projects/on-hold`, `projects/archived`, `areas/personal`, `resources/meetings`, `resources/source-material`, `decisions/by-date`, `decisions/by-project`, `reviews/monthly`, `reviews/quarterly`, `reviews/annual`, `archive/notes`, `archive/projects`, `archive/imports`, `_agent/memory/episodic`, `_agent/outputs/{briefs,drafts,summaries,synthesis}`, `_agent/skills/archived`) were recreated with a placeholder `README.md` in each so they persist.
 - **4. Add templates** — Done. All eight templates present (`_agent/templates/*`, `journal/templates/*`, `projects/project-template.md`, `decisions/decision-template.md`).
 - **5. Create initial notes** — Done. Seed/anchor notes present (`current-context.md`, `operator-preferences.md`, `active-setup.md`, initial session log, daily note, people notes, etc.).
 - **6. Validate Claude Code access** — Not yet verified. Confirm Claude Code can read/write the vault folder directly on the host.
 - **7. Enable the Obsidian Local REST API** — Done. Verified end-to-end: API v4.1.2 responds through the reverse proxy with a valid TLS cert, the bearer key authenticates, and a write → read → list → delete round-trip succeeded.
 - **8. Start the daily/session/review operating rhythm** — Not yet. Begins once the operator starts using the vault day-to-day.
@@ -0,0 +1,3 @@
 Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8
 https://goldbrainapi.mpm.to
@@ -0,0 +1 @@
 https://github.com/coddingtonbear/obsidian-local-rest-api
@@ -0,0 +1,25 @@
 # Agent Memory Index
 This is the entry point for Claude when reading memory. Files in `memory/`
 are read on demand based on the conversation.
 ## Read at session start
 1. `memory/profile.md` — facts about Jason, role, preferences
 2. The most relevant file under `memory/projects/` if a specific project is in play
 ## Write when
 - Jason says "remember", "save", or "log this"
 - A non-obvious decision is made → `memory/decisions/`
 - A working session ends with substance → `memory/sessions/`
 - Unsure where it goes → `memory/inbox.md`
 ## Folder map
 - `memory/profile.md` — persistent facts about Jason
 - `memory/projects/<slug>.md` — long-running project state
 - `memory/sessions/YYYY-MM-DD-<slug>.md` — per-conversation logs
 - `memory/people/<name>.md` — context about people
 - `memory/decisions/<date>-<slug>.md` — decision records
 - `memory/inbox.md` — uncategorized notes to triage later
@@ -0,0 +1,44 @@
 ---
 type: decision
 date: 2026-05-19
 project: cpas
 tags:
  - cpas
  - snapshot
  - backdating
  - audit
  - mpm
 ---
 # [[CPAS]] — back-dated insert refreshes downstream snapshots
 ## Context
 On `main` branch (post `ba2b631 documentation`, pre any roll-off model overhaul), the CPAS app stores `prior_active_points` as an immutable snapshot at violation insert time. The PDF endpoint reads this snapshot to render "Prior Active Points → New Total → Tier".
 When a violation is logged with a back-dated `incident_date` that precedes existing violations, the **new** violation's own snapshot is computed correctly, but **existing later-dated violations' snapshots are stale** — they were frozen before the back-dated event existed and so omit it from their 90-day prior window. Re-downloading their PDFs shows the pre-backdate prior/total/tier.
 ## Decision
 Refresh downstream snapshots on back-dated insert. Treat back-dating as a *timeline rewrite* and exempt it from the otherwise strict snapshot-immutability rule. Negate, restore, amend, and hard delete are NOT timeline rewrites and continue to leave snapshots alone.
 ## Implementation (in `server.js`)
 - New helper `recomputeSnapshotsAfter(employeeId, incidentDate)` finds all violations for the employee with `incident_date > new_date AND incident_date <= new_date + 90 days`, recomputes each via the existing `getPriorActivePoints()` formula, and only writes UPDATEs where the value changed.
 - `POST /api/violations` now wraps the insert + recompute in a single `db.transaction()` so a partial failure can't leave the system with a new violation and stale sibling snapshots.
 - When refresh affects ≥1 row, a `violation_snapshots_recomputed` audit entry is written with `reason: 'backdated_insert'`, `trigger_incident_date`, and an `affected[]` array of `{id, incident_date, old, new}` for full traceability.
 - Forward-dated inserts (the common case) do zero UPDATEs — affected query returns rows but the equality check skips them.
 ## Docs
 - `AGENTS.md` "Prior-Points Snapshot" section updated with the back-dating exception
 - `AGENTS.md` "What NOT to Do" updated — the "do not modify prior_active_points" line now carves out the back-dating path explicitly
 ## Verification
 - `node --check server.js` passes
 - Not runtime-tested in this session (better-sqlite3 won't compile on local Node v24 — see project file). Verification path: docker build, log V1 with a recent date, log V2 with an earlier back-dated date, re-download V1's PDF, confirm "Prior Active Points" now includes V2.
 ## Relationship to roll-off model overhaul
 The existing `projects/cpas.md` "Roll-off model fix (2026-05-27)" section describes a *different* implementation of `recomputeSnapshotsAfter` that widens the window to "all later violations" under a clean-cycle roll-off rule. That work is not on `main` as of today. If/when the roll-off overhaul lands on `main`, the helper's window scope will need to be widened to match (current scope is the legacy 90-day rolling window).
@@ -0,0 +1,37 @@
 ---
 type: decision
 status: shipped
 tags:
  - cpas
  - scoring
  - roll-off
  - mpm
 updated: 2026-05-27
 ---
 # [[CPAS]] roll-off: clean-cycle model, JS as source of truth
 ## Context
 System was implementing a literal per-violation rolling 90-day window. Jason reported that the handbook actually says "5 points roll off after 90 consecutive days of no violations" — i.e. any new violation should reset the countdown for everyone, not just for itself.
 ## Decision
 Adopt the clean-cycle model:
 1. Roll-off amount per cycle: **5 points, oldest first**
 2. Repeat cadence: **another full 90 clean days required** for each successive 5-point roll-off
 3. Reset trigger: **any new non-negated violation** (negated violations don't reset)
 Implement all standing math in JS (`lib/rolloff.js` `computeStanding()`). Drop the `active_cpas_scores` SQL view — oldest-first partial allocation isn't cleanly SQL-expressible, and having both a SQL and JS implementation invites divergence.
 ## Alternatives considered
 - Keeping the SQL view with the aggregate formula `total - 5*cycles_since_last_violation` and computing per-violation breakdown only in JS. Rejected: two implementations of the same rule = drift risk; dashboard scale at MPM is small enough that per-request JS computation is fine.
 - "All points roll off at once after 90 clean days" or "oldest entire violation rolls off." Rejected by Jason in clarifying questions.
 ## Consequences
 - `/api/employees/:id/expiration` response shape changed (was per-violation list, now `{ schedule: [...] }`). Frontend `ExpirationTimeline.jsx` updated to match — any third-party consumer of that endpoint would break.
 - Existing `prior_active_points` snapshots on pre-fix violation rows are stale; existing "Backfill Snapshots" admin button recomputes them under the new model on demand.
 - `recomputeSnapshotsAfter` no longer caps the affected window at +90 days — backdated inserts now scan all later violations, since under the new model an earlier total shift propagates indefinitely.
@@ -0,0 +1,152 @@
 ---
 type: decision
 date: 2026-05-28
 status: open
 tags: [obsidian, rest-api, bug-report, upstream]
 related: [[obsidian-memory-plugin]]
 ---
 # 2026-05-28 — File upstream issue for Obsidian Local REST API heading resolver bug
 ## Decision
 Draft and file a bug report at [coddingtonbear/obsidian-local-rest-api](https://github.com/coddingtonbear/obsidian-local-rest-api) for the heading-resolver failure that affects both `Target-Type: heading` PATCH and `GET /heading/...` reads.
 ## Why
 - Bug persists across a major plugin version bump (3.6 → 4.1.1), so it's not a regression in a transient build — it's a real defect that's been sitting in the resolver for at least one release.
 - The bug silently degrades the obsidian-memory skill: every documented PATCH-heading example in the skill's `references/api-reference.md` fails, forcing fallbacks to POST/PUT/frontmatter-PATCH. We have working workarounds, but they preclude surgical section edits that the skill instructs Claude to do.
 - Reproducer is small (4 curl calls) and deterministic — high signal-to-noise for a maintainer.
 - No alternative — only the upstream maintainer can fix it. Local workarounds will live in [[obsidian-memory-plugin]] indefinitely until this lands.
 ## How to apply
 - The full draft (title, repro, variations tried, ruled-out causes, suspected cause) is at `D:\REMOTE CODING\unifi-access-dashboard\obsidian-rest-api-issue-draft.md` on the dashboard machine.
 - Before filing: fill in two placeholders — Obsidian app version and vault filesystem.
 - After filing: come back to this decision and update `status:` from `open` → `filed` with the issue URL; if/when fixed, mark `resolved` and remove the workaround section from [[obsidian-memory-plugin]].
 ## Context that won't be in the issue body
 - All testing was done against the vault at `https://10.2.0.2:27124` from Claude Code sessions over the LAN.
 - The skill's documented PATCH-heading example (in `references/api-reference.md`) references a key that has a typo (`8c` instead of `e7` in one digit) — unrelated to this bug but worth noting if anyone tries to copy-paste from there.
 - `Target-Type: block` also fails with `invalid-target`. Probably the same resolver but not verified — left out of the issue body to keep the report tight; can add as a follow-up comment if relevant.
 ## Open
 - [ ] Fill in placeholders in the draft and post the issue
 - [ ] Paste the issue URL back here under "How to apply"
 - [ ] When fixed upstream: drop the workaround section from [[obsidian-memory-plugin]] and switch the skill back to PATCH-heading where it makes sense
 ## Draft body (copy-paste ready)
 See `obsidian-rest-api-issue-draft.md` on the dashboard machine, or mirrored below:
 ---
 ### Heading resolver broken: `Target-Type: heading` PATCH and `GET /heading/...` both fail on any valid heading (4.1.1)
 **Summary**
 In Obsidian Local REST API **4.1.1**, two endpoints that both rely on heading resolution always fail, even on a freshly written file with trivially-valid markdown headings:
 - `PATCH /vault/<path>` with `Target-Type: heading` → HTTP 400 `invalid-target`
 - `GET /vault/<path>/heading/<heading-text>` → HTTP 404 `Not Found`
 `Target-Type: frontmatter` PATCH on the same file works fine, so the PATCH route itself is healthy. The bug is isolated to the heading-resolution code path shared by these two endpoints.
 Also reproduced in **3.6** before upgrading; the 3.6 → 4.1.1 upgrade did not change the behavior.
 **Minimal reproducer**
 ```bash
 HOST="https://YOUR-HOST:27124"
 KEY="YOUR_API_KEY"
 # 1. PUT a fresh, simple file (HTTP 204 expected)
 cat > /tmp/repro.md <<'EOF'
 ---
 type: scratch
 ---
 # Hello
 ## Section A
 Content under A.
 ## Section B
 Content under B.
 EOF
 curl -sk -w "PUT: %{http_code}\n" -X PUT \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/repro.md \
  "$HOST/vault/scratch/repro.md"
 # 2. PATCH append under heading "Section A" — expected 200, actual 400 invalid-target
 echo "appended" > /tmp/p.md
 curl -sk -w "\nPATCH heading: %{http_code}\n" -X PATCH \
  -H "Authorization: Bearer $KEY" \
  -H "Operation: append" \
  -H "Target-Type: heading" \
  -H "Target: Section A" \
  -H "Content-Type: text/markdown" \
  --data-binary @/tmp/p.md \
  "$HOST/vault/scratch/repro.md"
 # 3. GET the heading's content via URL path — expected 200, actual 404
 curl -sk -w "\nGET heading: %{http_code}\n" \
  -H "Authorization: Bearer $KEY" \
  "$HOST/vault/scratch/repro.md/heading/Section%20A"
 # 4. CONTROL: PATCH frontmatter — works (HTTP 200)
 curl -sk -w "\nPATCH frontmatter: %{http_code}\n" -X PATCH \
  -H "Authorization: Bearer $KEY" \
  -H "Operation: replace" \
  -H "Target-Type: frontmatter" \
  -H "Target: type" \
  -H "Content-Type: application/json" \
  --data '"updated"' \
  "$HOST/vault/scratch/repro.md"
 ```
 **Actual output**
 ```
 PUT: 204
 {"message":"...invalid-target","errorCode":40080}  PATCH heading: 400
 {"message":"Not Found","errorCode":40400}          GET heading: 404
 PATCH frontmatter: 200
 ```
 **Variations tried (all fail identically with `invalid-target` / 404)**
 - Single-word heading (`Target: Section`) and multi-word (`Target: Section A`)
 - URL-encoded header value (`Target: Section%20A`)
 - `Operation: append`, `prepend`, and `replace`
 - Both freshly-PUT files (LF endings) and files originally written by Obsidian
 - `Target-Type: block` also returns `invalid-target`
 **What I ruled out**
 - CRLF / BOM in source file — fresh file was written by `curl --data-binary` with LF-only content
 - Spaces in heading text — single-word headings fail the same way
 - URL encoding of `Target:` header value — raw and percent-encoded both fail
 - PATCH route generally broken — `Target-Type: frontmatter` succeeds on the same file
 - Version regression in 4.1.1 — same behavior in 3.6 before upgrading
 **Environment**
 - Obsidian Local REST API: 4.1.1 (also reproduced in 3.6)
 - Obsidian: `<fill in>`
 - OS hosting Obsidian: `<fill in>`
 - Client: curl over HTTPS to :27124 with `-k` (self-signed cert)
 - Vault filesystem: `<fill in>`
 **Suspected cause**
 Since `GET /vault/<path>/heading/<name>` and `Target-Type: heading` PATCH fail in lockstep (and frontmatter resolution works fine on the same request path), the most likely location is whichever helper enumerates headings within a parsed file's AST — perhaps it's getting an empty list, or matching on the wrong field.
 Happy to bisect or add logging if you can point me at the relevant file.
@@ -0,0 +1,13 @@
 ---
 type: inbox
 updated: 2026-05-27
 ---
 # Inbox
 Untriaged memory entries. One line per item, prefixed with date.
 Promote to the right file when convenient.
 - 2026-05-27 — `better-sqlite3` native build fails on local Node v24 (gyp errors); builds fine in `node:20-alpine`. For projects using it (cpas at minimum), verify via container build rather than local `node` invocation.
 - 2026-05-19 — CPAS: shipped back-dated-insert snapshot refresh on `main` (helper `recomputeSnapshotsAfter` in server.js, transactional, audit-logged as `violation_snapshots_recomputed`). Decision record: [[2026-05-19-cpas-backdated-snapshot-refresh]]. Note: this lives on `main` which is still the legacy 90-day-rolling model — different universe from the roll-off overhaul described in [[cpas]]. Window scope will need widening when roll-off lands on `main`.
@@ -0,0 +1,17 @@
 ---
 type: people
 status: active
 tags:
  - mpm
  - boss
  - ceo
 updated: 2026-05-30
 ---
 # Bryan Gilliom
 CEO of Message Point Media (MPM). Jason's boss.
 ## Notes
 - Authored the "Moving Forward" / Working Framework document governing Mitch Tankersley's diminished-autonomy period (see [[mitch-tankersley]]).
 - Jason is waiting on Bryan to provide two values to fill into Mitch's Working Framework: the Amazon no-approval spend threshold, and the framework's effective date.
@@ -0,0 +1,130 @@
 ---
 type: people
 status: active
 tags:
  - employee
  - performance
  - diminished-autonomy
  - daily-tracker
  - mitch
  - mpm
 updated: 2026-05-30
 ---
 # Mitch Tankersley — Daily Progress Tracker
 ## About
 Mitch Tankersley is an employee at MPM (Message Point Media) currently operating under **diminished autonomy** — a structured accountability period requiring daily check-in and check-out reporting to Jason.
 **Manager:** Jason (jason@messagepoint.tv)
 **Status:** Diminished autonomy — daily task accountability required
 **Tracker started:** 2026-05-28
 **Reporting method:** Mitch reports his check-ins and check-outs directly to Jason via **Google Chat**. Jason logs all entries here as his direct supervisor — Mitch does not write to this file himself.
 ---
 ## Working Framework
 Condensed from the supervisor's "Moving Forward" document (MPM internal, confidential). Defines the terms of the diminished-autonomy period.
 ### Schedule
 - In-office Monday–Friday, **9:00 AM – 6:00 PM**. No remote work under any circumstance.
 - Any absence during business hours requires advance supervisor approval and is recorded as PTO.
 - Exception: authorized out-of-town deployments coordinated through Finance.
 ### Daily Check-In (Start & End of Day)
 - **Start of day:** Message supervisor with priorities before starting work.
 - **End of day:** Wrap message with accomplishments — include links, artifacts, or photos where possible. "If you built it, show it."
 - Suggested templates:
  - **SOD** — "Morning. Today: [1] [task] · [2] [task] · [3] [task]. Blockers: [none / note]"
  - **EOD** — "Done for the day. Completed: [item — link or pic]. In progress: [item, where I left off]. Tomorrow: [carry-forward]. Artifacts: [attach or link anything produced]"
 ### Company Vehicle (interim — pending purchase completion)
 - Business use only; no personal use.
 - Pay for fuel out of pocket; submit business miles for reimbursement at the standard IRS mileage rate.
 - Keep a mileage log — date, destination, business purpose, miles.
 - Once vehicle purchase is finalized, terms convert to the loan agreement.
 ### Spending & Expenses
 - Restricted Spend card with Finance-managed limits.
 - Approval required before purchasing — text Tiffany or Jason for fast turnaround.
 - Amazon under $[limit TBD]: no approval needed; use company shared payment method.
 - **Itemized receipts — no exceptions.** Every purchase requires an itemized receipt showing exactly what was bought; a total-only receipt is not sufficient. Missing or non-itemized receipts result in the pre-paid card not being replenished, or the amount deducted directly from his paycheck to replenish it.
 ### Travel Coordination
 - All airfare, lodging, and vehicle rentals booked directly by MPM Finance.
 - Submit travel needs to Finance at least **48 hours in advance**.
 - All travel spend via Ramp pre-paid card — itemized receipts required (see Spending).
 - Standard in-office schedule resumes immediately upon return to Birmingham.
 ### Systems & Credentials
 - All accounts, software licenses, subscriptions, and credentials are MPM property at all times.
 - Work with Jason to move all company-related accounts and services to a company payment method.
 - Document all logins and passwords in Shared Apple Passwords.
 - Access is subject to review, reassignment, or revocation at management's discretion without advance notice.
 ### Knowledge Transfer & Documentation
 - Active documentation of all systems, processes, and integrations he owns or manages.
 - Use Plaud to record walkthroughs and process notes — reduces overhead of writing from scratch.
 - Coordinate with Jason on documentation priorities, format, and handoff.
 - Junior shadow oversight of work product is in effect.
 ### Path Forward
 - Every **90 days of clean performance** is an automatic step toward restored autonomy (flexibility, trust, discretion over time and tools). [[cpas]]
 ---
 ## Instructions for Daily Entries
 Each workday requires two entries: a **Morning Check-In** and an **End-of-Shift Check-Out**.
 ### Morning Check-In (start of shift)
 Mitch submits the tasks he **plans** to work on that day before beginning work.
 Format:
 ```
 ### YYYY-MM-DD — Check-In
 **Time:** HH:MM AM/PM
 **Planned Tasks:**
 - [ ] Task description
 - [ ] Task description
 - [ ] Task description
 ```
 ### End-of-Shift Check-Out (end of shift)
 Mitch submits the tasks he **actually made progress on** before leaving.
 Format:
 ```
 ### YYYY-MM-DD — Check-Out
 **Time:** HH:MM AM/PM
 **Progress Made:**
 - [x] Task completed / description of progress
 - [-] Task partially completed — notes on where it stands
 - [ ] Task not started — brief reason if applicable
 **Notes:** (optional — blockers, context, carryover)
 ```
 ---
 ## Daily Log
 ### 2026-05-28 — Check-Out
 **Time:** End of shift
 **Progress Made:**
 - [x] Mobile screen mounting patterns — completed
 - [-] Tucson 3D prints — in progress, status unknown
 **Notes:** Reported via Google Chat to Jason.
 ### 2026-05-29 — Check-In
 **Status:** Never submitted. No morning check-in received.
 ### 2026-05-29 — Check-Out
 **Time:** End of shift
 **Progress Made:**
 - [-] Tucson 3D prints — still in progress. Mitch reports it is "a very difficult print, consuming my time, prompting redesign. Trying to improve final result." No other updates given.
 **Notes:** No morning check-in was submitted for this date.
 **Manager assessment (Jason):** This appears to be an inefficient use of time. Tucson is a one-off project with no real gain versus simply outsourcing the work. Continued in-house iteration/redesign is not justified by the payoff.
@@ -0,0 +1,85 @@
 ---
 type: profile
 updated: 2026-05-28
 ---
 # Profile
 > Persistent facts about Jason. Append observations as they emerge;
 > promote stable ones to a top-level section.
 ## Role
 Jason works at **Message Point Media (MPM)** — a digital signage company (~2,000-display installed base). He is a developer and builder who runs Claude CoWork skills and plugins for the MPM team. He also runs his own wireless ISP, **ALWISP** (Alabama mesh networking), and builds a wide range of personal and commercial self-hosted applications.
 ## Communication preferences
 ## Tools and stack
 ### Preferred languages and runtimes
 - **Primary:** Node.js + TypeScript for application work
 - **Secondary:** Python for tooling, automation, and AI integrations (FastAPI)
 - **Frontend:** React 18 + TypeScript + Vite; Tailwind CSS; Svelte (used in pnger)
 - **ORM/DB:** Prisma + SQLite as default; PostgreSQL for production-grade apps
 - **Build/deploy:** Single Docker container pattern — nearly every app ships as one container
 ### Infrastructure
 - Runs an **Unraid** server as his primary self-hosting platform
 - Personal Gitea at **git.alwisp.com** — personal repos under `jason/` user
 - Work Gitea at **git.mpm.to** — MPM org repos (plugin: `git-mpm`)
 - **TotalMCP** unified MCP gateway runs at `10.2.0.35:8811` on Unraid `br0`
 - Obsidian vault accessible at `10.2.0.2:27124` (self-signed cert, `-k` always needed)
 - Gitea CI runners used for building Docker images (e.g., stepview)
 ### CoWork plugins and skills
 Jason maintains a suite of Claude CoWork plugins at git.mpm.to and git.alwisp.com. Key ones:
 - `mpm-brand-voice-plugin` — MPM brand voice enforcement
 - `odoo-mpm-plugin` / `odoo-plugin-creation` — Odoo ERP access
 - `display-catalog-plugin` — MP.TV product catalog generation
 - `prompt-optimizer` — transforms rough requests into polished prompts
 - `git-personal` — personal Gitea (git.alwisp.com)
 - `git-mpm` — work Gitea (git.mpm.to)
 ## Personal projects (git.alwisp.com/jason)
 | Repo                   | What it is                                                                |
 | ---------------------- | ------------------------------------------------------------------------- |
 | **[[alwisp]]**         | Dockerized LAMP website for his wireless ISP                              |
 | **[[breedr]]**         | Dog breeding genealogy management system                                  |
 | **[[codedump]]**       | Internal dashboard for tracking AI tools and coding projects              |
 | **[[codexium-odoo]]**  | CODEXIUM MRP platform — Odoo variant                                      |
 | **[[cpas]]**           | CPAS violation tracker with Puppeteer PDF generation                      |
 | **[[email]]**          | Google Workspace email signature manager                                  |
 | **[[fabdash]]**        | Fabrication project management and scheduling dashboard                   |
 | **[[family-planner]]** | Self-hosted family dashboard (calendars, chores, meals, screensaver)      |
 | **[[inven]]**          | Inventory management with BOMs, orders, invoicing on SQLite               |
 | **[[memer]]**          | Self-hosted meme gallery with Telegram/SMS quick-share                    |
 | **[[mempalace]]**      | Server-mode MemPalace fork — shared AI memory palace over LAN             |
 | **[[mrp]]**            | CODEXIUM MRP — manufacturing resource planning platform                   |
 | **[[mrp-qrcode]]**     | MRP with QR traveler cards, operator scan flow, in-browser STEP viewer    |
 | **[[nyaa-crawler]]**   | Nyaa.si anime torrent tracker and auto-downloader                         |
 | **[[pos]]**            | Full-stack TypeScript point-of-sale (Android + Node + React)              |
 | **[[rack-planner]]**   | RackMapper — network rack visualizer and service dependency mapper        |
 | **[[stepview]]**       | Self-hosted in-browser 3D STEP file viewer (OpenCascade WASM + three.js)  |
 | **[[storybid]]**       | Charity auction platform with PWA offline bidding and Stripe payments     |
 | **[[totalmcp]]**       | Unified MCP gateway for the ALPHA stack (Claude Code, Codex, Antigravity) |
 | **[[ui-tracker]]**     | Unifi Store stock monitor with Telegram alerts                            |
 | **[[pnger]]**          | PNG editor/resizer — TypeScript + Svelte + Sharp                          |
 | **[[qrknit]]**         | Commercial QR code generator and URL shortener (own org: qrknit/qrknit)   |
 ## Notes
 - Gitea file uploads must use Python + temp files for base64 encoding — `echo -n | base64` causes corruption
 - Nearly all apps follow the single-container Docker pattern designed for Unraid deployment
 - Jason builds for himself and for MPM — personal projects skew toward home automation, media, and fabrication tooling
 ### Deployment workflow
 - **CI/CD:** Push to Gitea (`git.alwisp.com`) → Gitea Actions → Docker build → push to `registry.alwisp.com`
 - **Gitea Actions runner image:** `catthehacker/ubuntu:act-latest`
 - **Image tag pattern:** `registry.alwisp.com/{owner}/{repo}:latest`
 - **Deployment target:** Unraid Docker GUI (manual container creation after image push)
 - **Network preference:** Always **Custom: br0** — dedicated LAN IP per container, subnet `10.2.0.0/24`; never bridge; reason: direct app-to-app communication without port mapping
 - **Volume root:** `/mnt/user/appdata/{app-name}/` on Unraid host
 - **Privileged containers:** OFF by default
 - **Tailscale on containers:** OFF by default
 - Full deployment reference: [[unraid-deployment]]
@@ -0,0 +1,77 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/agents
 repo_url: https://git.alwisp.com/jason/agents
 language: Markdown
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # agents
 **Repository:** [jason/agents](https://git.alwisp.com/jason/agents) · branch `main` · Markdown
 ## Summary
 Portable drop-in markdown instruction suite for AI coding agents — provides AGENTS.md, skill index, routing hubs, and specialized skill files to copy into any repo
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # Drop-In Agent Instruction Suite
 This repository is a portable markdown instruction pack for coding agents.
 Copy these files into another repository to give the agent:
 - a root `AGENTS.md` entrypoint,
 - a central skill index,
 - category hubs for routing,
 - specialized skill files for common software, docs, UX, marketing, and ideation tasks.
 ## Structure
 - `AGENTS.md` - base instructions and routing rules
 - `DEPLOYMENT-PROFILE.md` - agent-readable prefilled deployment defaults
 - `INSTALL.md` - copy and customization guide for other repositories
 - `PROJECT-PROFILE-WORKBOOK.md` - one-time questionnaire for staging defaults
 - `SKILLS.md` - canonical skill index
 - `ROUTING-EXAMPLES.md` - representative prompt-to-skill routing examples
 - `hubs/` - category-level routing guides
 - `skills/` - specialized reusable skill files
 ## Design Goals
 - Plain markdown only
 - Cross-agent portability
 - Implementation-first defaults
 - On-demand skill loading instead of loading everything every session
 - Context-efficient routing for large skill libraries
 - Prefilled deployment defaults without per-install questioning
 - Repo-local instructions take precedence over this bundle
 ## Intended Workflow
 1. The agent reads `AGENTS.md`.
 2. The agent reads `DEPLOYMENT-PROFILE.md` when it is filled in.
 3. The agent checks `SKILLS.md`.
 4. The agent opens only the relevant hub and skill files for the task.
 5. The agent combines multiple skills when the task spans several domains.
 ## Core Categories
 - Software development
 - Debugging
 - Documentation
 - UI/UX
 - Marketing
 - Brainstorming
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,77 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/alwisp
 repo_url: https://git.alwisp.com/jason/alwisp
 language: Hack
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # alwisp
 **Repository:** [jason/alwisp](https://git.alwisp.com/jason/alwisp) · branch `main` · Hack
 ## Summary
 Dockerized LAMP stack website for ALWISP, Alabama's wireless ISP and mesh networking company
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # ALWISP – Mesh Network Solutions
 > Dockerized LAMP stack website for Alabama's wireless ISP and mesh networking company.
 ---
 ## Table of Contents
 - [Stack Overview](#stack-overview)
 - [Installation – Unraid](#installation--unraid)
 - [Environment Variables](#environment-variables)
 - [Project Structure](#project-structure)
 - [Roadmap & Milestones](#roadmap--milestones)
 - [Updating the Site](#updating-the-site)
 - [Useful Commands](#useful-commands)
 ---
 ## Stack Overview
 | Container | Image | Purpose |
 |---|---|---|
 | `alwisp_web` | PHP 8.2 + Apache | Serves the website |
 | `alwisp_db` | MySQL 8.0 | Database (internal only) |
 | `alwisp_pma` | phpMyAdmin (optional) | DB admin UI on port 8080 |
 Each container is deployed individually through the Unraid Container Builder and connected via the `br0` bridge network, giving both the web container and the database container their own dedicated LAN IP addresses. The web container reaches the database by its fixed LAN IP. Data persists in a named Docker volume (`db_data`) and survives container restarts and rebuilds.
 ---
 ## Installation – Unraid
 ### Prerequisites
 - Unraid 6.10 or later
 - **Community Applications** plugin installed
 - **Docker** enabled (Settings → Docker → Enable Docker: Yes)
 - **User Scripts** plugin (recommended, for scheduled tasks)
 - `br0` enabled — your Unraid host NIC must be bridged (Settings → Network → Enable Bridging: Yes)
 - Decide on **two free LAN IPs** before you start — one for the web container, one for the database. Example: `192.168.1.100` (web) and `192.168.1.101` (db). Reserve these in your router's DHCP settings so they are never auto-assigned.
 ---
 ### Step 1 – Clone the repository onto your Unraid cache drive
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,75 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/breedr
 repo_url: https://git.alwisp.com/jason/breedr
 language: JavaScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # breedr
 **Repository:** [jason/breedr](https://git.alwisp.com/jason/breedr) · branch `main` · JavaScript
 ## Summary
 Reactive dog breeding genealogy management system — pedigree mapping, litter records, and ancestor/descendant views in a single Docker container
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # BREEDR - Dog Breeding Genealogy Management System
 A reactive, interactive dog breeding genealogy mapping system for professional kennel management.
 ---
 ## 🌟 Recent Highlights (v0.8.0)
 - **✅ Reverse Pedigree** — Toggle between ancestors and descendants view for full lineage tracking.
 - **✅ External Dog Mapping** — Assign parents to external dogs, allowing for full genealogy of outside lines.
 - **✅ Universal Parent Selection** — Select any dog (kennel or external) as a sire/dam from any profile.
 ---
 ## 🚀 Quick Start
 ### 1. Docker Deployment (Recommended)
 ```bash
 git clone https://git.alwisp.com/jason/breedr.git
 cd breedr
 docker-compose up -d --build
 ```
 Access at: `http://localhost:3000`
 ### 2. Manual Development Setup
 ```bash
 npm install
 npm run dev
 ```
 > **Note:** The database initializes automatically on first boot. No manual migrations are required.
 ---
 ## 🐕 Managing Your Kennel
 - **Adding Dogs**: Go to the **Dogs** page, click **Add New Dog**. You can mark dogs as **External** if they aren't in your kennel but are needed for pedigree mapping.
 - **Champion Tracking**: Toggle the **Champion** status to title dogs. Offspring will automatically display the "Champion Bloodline" badge.
 - **Photo Management**: Multiple high-quality photos per dog with a compact gallery view.
 - **Litter Tracking**: Link puppies to breeding records automatically to track weight and health from birth.
 ## 🧬 Breeding & Genetics
 - **Interactive Pedigree**: 5-generation trees with zoom/pan. Toggle the **Reverse Pedigree** switch to see descendant lineage.
 - **Trial Pairing Simulator**: Calculate Wright's Inbreeding Coefficient (COI) instantly. Identifies common ancestors and providing risk badges (Low/Moderate/High).
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,84 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/codedump
 repo_url: https://git.alwisp.com/jason/codedump
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # codedump
 **Repository:** [jason/codedump](https://git.alwisp.com/jason/codedump) · branch `main` · TypeScript
 ## Summary
 Internal dashboard for tracking AI tools and coding projects — shows completion status, links documentation, and manages team access via admin accounts and PINs
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 _Source: PROJECT.md_
 # CODEDUMP
 Internal dashboard for tracking AI tools and coding projects. Provides a high-level overview of what the team is building, what tools are available, and the completion status of active work — all in one place.
 ---
 ## Purpose
 CODEDUMP gives teams a single place to:
 - Track AI tools and coding projects with completion percentages
 - Attach markdown documentation and project files
 - Link to internal/external URLs and Google Drive sources
 - Highlight new tools available to the team
 - Manage access via admin accounts and 4-digit user PINs
 ---
 ## Tech Stack
 | Layer | Technology |
 |---|---|
 | Frontend | React 18 + TypeScript + Vite |
 | Styling | Tailwind CSS (dark mode, CSS variable theming) |
 | Backend | Node.js + Express + TypeScript |
 | Database | SQLite via `better-sqlite3` |
 | Auth | JWT (12h expiry) + bcryptjs (admin passwords) + HMAC-SHA256 (user PINs) |
 | File uploads | Multer (local disk storage) |
 | Markdown | `react-markdown` + `remark-gfm` |
 | Container | Docker (multi-stage build, single container) |
 ---
 ## Project Structure
 ```
 codedump/
 ├── client/                          # React frontend
 │   ├── src/
 │   │   ├── api/index.ts             # Typed fetch wrappers (JWT injected automatically)
 │   │   ├── hooks/
 │   │   │   ├── useAuth.ts           # AuthContext — JWT storage, login/logout
 │   │   │   └── useSettings.ts       # SettingsContext — branding, accent color
 │   │   ├── components/
 │   │   │   ├── layout/
 │   │   │   │   ├── Layout.tsx       # App shell (sidebar + outlet)
 │   │   │   │   └── Sidebar.tsx      # Nav — auth-aware, admin section, logout
 │   │   │   ├── projects/
 │   │   │   │   ├── ProjectCard.tsx  # Card with progress bar, links, tags
 │   │   │   │   └── ProjectForm.tsx  # Create/edit form with color picker
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,56 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/codexium-odoo
 repo_url: https://git.alwisp.com/jason/codexium-odoo
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # codexium-odoo
 **Repository:** [jason/codexium-odoo](https://git.alwisp.com/jason/codexium-odoo) · branch `main` · TypeScript
 ## Summary
 CODEXIUM MRP platform (Odoo variant) — modular Manufacturing Resource Planning with React, Express, Prisma, SQLite, full CRM, inventory, and BOM management
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # CODEXIUM
 Foundation release for a modular Manufacturing Resource Planning platform built with React, Express, Prisma, SQLite, and a single-container Docker deployment.
 ## Documentation Maintenance
 - Keep [CHANGELOG.md](D:/CODING/mrp-codex/CHANGELOG.md) updated for shipped features, workflow changes, and notable operational updates.
 - Keep [README.md](D:/CODING/mrp-codex/README.md), [INSTRUCTIONS.md](D:/CODING/mrp-codex/INSTRUCTIONS.md), [STRUCTURE.md](D:/CODING/mrp-codex/STRUCTURE.md), [ROADMAP.md](D:/CODING/mrp-codex/ROADMAP.md), [SHIPPED.md](D:/CODING/mrp-codex/SHIPPED.md), and [UNRAID.md](D:/CODING/mrp-codex/UNRAID.md) aligned when changes affect their scope.
 Current foundation scope includes:
 - authentication and RBAC
 - company branding and theme settings, including startup brand-theme hydration across refresh
 - CRM customers and vendors with create/edit/detail workflows
 - CRM search, filtering, status tagging, and reseller hierarchy
 - CRM contact history, account contacts, and shared attachments
 - inventory item master, BOM, warehouse, stock-location, and stock-transaction flows
 - inventory transfers, reservations, and available-stock visibility
 - inventory SKU master builder with family-scoped sequence generation and branch-aware taxonomy management
 - staged thumbnail image attachment on inventory item create/edit workflows, with detail-page thumbnail display
 - sales quotes and sales orders with searchable customer and SKU entry
 - sales approvals, approval stamps, automatic revision history, and revision comparison on quotes and sales orders
 - purchase orders with searchable vendor and SKU entry, restricted to purchasable inventory items
 - purchase-order revision history and revision comparison across commercial and receipt changes
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,96 @@
 ---
 type: project
 status: active
 tags:
  - cpas
  - mpm-internal
  - sqlite
  - express
  - react
  - puppeteer
  - mpm
 updated: 2026-05-27
 ---
 # CPAS Violation Tracker
 Internal MPM tool for tracking employee CPAS (Corrective Performance Action System) violations. Single Docker container, self-contained. Repo: `git.alwisp.com/jason/cpas` (also pushed to git.mpm.to as MPM internal).
 Local path: `F:\CODING\cpas\cpas`.
 ## Stack
 - **Backend:** Node.js + Express + `better-sqlite3` (better-sqlite3 won't compile on local Node v24 — builds fine in `node:20-alpine` Docker)
 - **Frontend:** React 18 + Vite, axios for API calls, dark theme inline styles (no Tailwind here)
 - **PDF:** Puppeteer-core driving Chromium in the container
 - **DB:** SQLite at `/data/cpas.db`, WAL mode, foreign keys ON. Schema lives in `db/schema.sql` with programmatic migrations in `db/database.js`
 - **Port:** 3001
 - **Deployment:** Single container on Unraid, volume `/data` for the DB
 ## Key architecture notes
 - Violations carry a 90-day rolling window. Each violation stores a `prior_active_points` **snapshot** at submission so its PDF always shows the score *as it was on the incident date*. Snapshots auto-refresh on back-dated inserts and via a manual "Backfill Snapshots" button per employee.
 - Negate = soft delete (reversible). Hard delete is also supported. Both are audit-logged.
 - Append-only `audit_log` table records every write action.
 - Custom violation types stored in `violation_types` table; type_key prefixed with `custom_` to avoid collisions.
 ## Authentication (added 2026-05-27)
 - **Login screen** gates the entire app. Every `/api/*` route except `/api/health` and `/api/auth/login` requires a `Bearer` token.
 - **Bootstrap admin** created/synced from `ADMIN_USERNAME` / `ADMIN_PASSWORD` env vars on every container start — its password is owned by Docker (cannot be changed in UI; UI changes overwritten on restart). Default `ADMIN_PASSWORD=changeme` must be overridden at deploy.
 - **Password hashing:** Node built-in `crypto.scryptSync` (no new deps). Stored as `scrypt$<saltHex>$<hashHex>`.
 - **Sessions:** DB-backed in `sessions` table, 7-day TTL, token = `crypto.randomBytes(32).toString('hex')`. Sessions survive container restarts.
 - **Roles:** `admin` and `user`. Admin sees a **Users** button in the nav to add/delete users and reset passwords.
 - **Frontend:** axios request interceptor injects `Authorization: Bearer <token>` from localStorage on every call; response interceptor clears token + falls back to login on 401. Covers all components including blob PDF downloads (which use axios with `responseType: 'blob'`, no direct anchor links).
 ## Files of note
 - `auth.js` — auth module (hashing, sessions, user CRUD, middleware, `bootstrapAdmin()`)
 - `server.js` — `app.use('/api', auth.requireAuth)` placed after `/api/health` and `/api/auth/login` so those stay public; all routes below are protected
 - `db/database.js` — `users` and `sessions` tables added
 - `client/src/auth.js` — axios interceptors + token helpers
 - `client/src/components/LoginModal.jsx` — login popup
 - `client/src/components/UserManagementModal.jsx` — admin Users panel
 - `client/src/App.jsx` — auth gate (`authChecked`/`user` state), logout button, conditional Users button
 - `Dockerfile` — `ENV ADMIN_USERNAME=admin` and `ENV ADMIN_PASSWORD=changeme` defaults
 - `client/src/components/ReadmeModal.jsx` — in-app admin guide; updated with "Authentication & User Accounts" section
 - `README_UNRAID_INSTALL.md` — adds steps 5.5 Variables 3+4 (admin env vars), login note in Verify, troubleshooting rows for forgotten admin password
 ## Current status
 Authentication shipped (2026-05-27). Backend syntax-checks pass; client builds clean. Could not verify locally because better-sqlite3 fails to compile on Node v24 — verification requires building/running the Docker container.
 ## Open considerations
 - No expanded role model yet (only admin/user). Future: supervisor-scoped or read-only roles.
 - No password-change UI for non-admin users (they ask an admin to reset). Could add.
 - Sessions table has no periodic cleanup of expired tokens; expired tokens are pruned lazily on use.
 ## Roll-off model fix (2026-05-27)
 Earlier "90-day rolling window per violation" wording above is **superseded**. The handbook actually specifies a *clean-cycle* roll-off: points only retire after 90 consecutive days with NO new violation, and any new non-negated violation resets the clock for the whole employee. Each completed clean cycle removes 5 points oldest-first; each successive 5-point roll-off needs another fresh 90 clean days.
 The old per-violation expiry was rolling whole violations off independently 90 days from their own incident date — so a new violation didn't reset the countdown on earlier ones. Bug surfaced by Jason; fixed same session.
 ### Implementation
 - `lib/rolloff.js` (new) — pure `computeStanding(violations, asOf)` is the **single source of truth**. Returns `{ activePoints, totalPoints, rolledOffPoints, cycles, violationCount, lastViolationDate, nextRolloffDate, perViolation, schedule }`. Verified with scenario tests (single violation, two-violation reset case, multi-cycle decay).
 - `active_cpas_scores` SQL view **retired** (dropped in `db/database.js`, removed from `schema.sql`). SQL can't cleanly express oldest-first partial allocation, so all standing computation moved to JS to avoid SQL/JS divergence.
 - `server.js` rewired: `/score`, `/dashboard`, `/expiration`, `getPriorActivePoints`, PDF endpoint, and `recomputeSnapshotsAfter` all go through the helper. Dashboard now fetches all non-negated violations once, buckets per employee, and computes in JS (fine at MPM scale).
 - `/expiration` response shape changed from a list of per-violation rows to `{ active_points, last_violation_date, next_rolloff_date, schedule: [{date, points_off, points_after, days_remaining}] }`.
 - `recomputeSnapshotsAfter` window widened: under the new model an earlier backdated insert shifts every later violation's snapshot (not just within 90 days), so it now scans all later violations.
 - Frontend: `ExpirationTimeline.jsx` re-rendered as a roll-off schedule with a "clock resets on any new violation" note. `ViolationForm.jsx` label changed from "violations in last 90 days" → "active violations".
 ### Migration / backfill posture
 - **Automatic on restart:** every live read (dashboard, score, expiration, PDF current standing, prior points for NEW inserts).
 - **Needs manual backfill:** `prior_active_points` already stored on pre-fix violation rows — they were frozen under the old rule. Existing "Backfill Snapshots" button (`POST /api/employees/:id/recompute-snapshots`) rewrites them per employee. Skip unless historical PDFs matter.
 ### Files touched
 - `lib/rolloff.js` (new)
 - `db/database.js` (drop view)
 - `db/schema.sql` (drop view)
 - `server.js` (helper require, `loadViolations`/`standingFor`, all 5 endpoint rewires)
 - `client/src/components/ExpirationTimeline.jsx` (full rewrite of render)
 - `client/src/components/ViolationForm.jsx` (label tweak)
@@ -0,0 +1,74 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/email
 repo_url: https://git.alwisp.com/jason/email
 language: HTML
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # email
 **Repository:** [jason/email](https://git.alwisp.com/jason/email) · branch `main` · HTML
 ## Summary
 Self-hosted Dockerized Google Workspace email signature manager — syncs users from Google Directory and pushes HTML signatures directly to Gmail via API
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # Email Signature Manager
 A self-hosted, Dockerized Google Workspace email signature manager.
 Runs as a single container — designed for Unraid but works on any Docker host.
 See [INSTALL.md](INSTALL.md) for Unraid-specific instructions.
 ## Features
 - **Automated Directory Sync** — Pulls user data from Google Workspace Directory API
 - **HTML Signature Renderer** — Per-user signatures via Handlebars templates
 - **Gmail API Integration** — Pushes signatures directly to Gmail (web + mobile)
 - **Nightly Sync** — Automated batch push via configurable cron schedule
 - **Web Admin UI** — Management dashboard with live template editor
 - **Template Versioning** — Save multiple versions and recall them later
 - **Test Mode** — Single-user push for safe testing and onboarding
 - **Audit Logging** — SQLite-backed history of every push event
 - **Secure Access** — Basic auth protected management interface
 - **Self-Hosted** — Single container with internal SQLite, no external DB needed
 ---
 ## Logo & Image Hosting
 All images referenced in the signature template must be publicly accessible via HTTPS.
 The default logo URL is:
 ```
 https://alwisp.com/uploads/logo.png
 ```
 Upload your logo and any other signature images to `https://alwisp.com/uploads/` and
 reference them by full URL in the template. The logo URL can also be changed live
 in the Template Editor UI without rebuilding the container.
 ---
 ## Environment Variables
 All secrets and configuration are passed as **environment variables at runtime**.
 No `.env` file is committed to this repo — see `.env.example` for all variable names.
 | Variable | Description | Default |
 |---|---|---|
 | `GOOGLE_ADMIN_EMAIL` | Workspace admin email (e.g. jason@messagepoint.tv) | *(required)* |
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,79 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/fabdash
 repo_url: https://git.alwisp.com/jason/fabdash
 language: JavaScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # fabdash
 **Repository:** [jason/fabdash](https://git.alwisp.com/jason/fabdash) · branch `main` · JavaScript
 ## Summary
 FABDASH: fabrication project management and scheduling dashboard — dark/gold-themed React + Flask + SQLite single-container app for fabrication workflow management
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # FABDASH
 **Fabrication Dashboard** — A sleek, modern project management & scheduling application built for fabrication workflows.
 Repo: https://github.com/jasonMPM/fabdash
 ---
 ## Table of Contents
 - [Overview](#overview)
 - [Tech Stack](#tech-stack)
 - [Project Structure](#project-structure)
 - [Features](#features)
 - [Interaction Reference](#interaction-reference)
 - [Keyboard Shortcuts](#keyboard-shortcuts)
 - [API Reference](#api-reference)
 - [Component Architecture](#component-architecture)
 - [Unraid Installation](#unraid-installation)
 - [Adding Your Logo](#adding-your-logo)
 - [Updating FabDash on Unraid](#updating-fabdash-on-unraid)
 - [Local Development](#local-development)
 - [Environment Variables](#environment-variables)
 - [Database Schema](#database-schema)
 - [Roadmap](#roadmap)
 ---
 ## Overview
 FabDash is a self-hosted, full-stack project management dashboard built for fabrication teams. It features a large interactive calendar, multi-deliverable project tracking, drag-and-drop scheduling, a per-project Focus View timeline, a redesigned workload heatmap with per-status color-coded grids, an agenda panel, right-click context menus, keyboard shortcuts, and a collapsible branded sidebar — all wrapped in a dark/gold UI and deployed as a single Docker container with no external dependencies.
 ---
 ## Tech Stack
 ### Frontend
 | Package | Version | Purpose |
 |---|---|---|
 | React | ^18.3.1 | UI framework |
 | Vite | ^5.4.11 | Build tool and dev server |
 | Tailwind CSS | ^3.4.15 | Utility-first styling |
 | @fullcalendar/core | 6.1.15 | FullCalendar core (pinned — version must match all FC packages) |
 | @fullcalendar/react | 6.1.15 | Calendar component |
 | @fullcalendar/daygrid | 6.1.15 | Month/week grid view |
 | @fullcalendar/timegrid | 6.1.15 | Time-slot view |
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,82 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/family-planner
 repo_url: https://git.alwisp.com/jason/family-planner
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # family-planner
 **Repository:** [jason/family-planner](https://git.alwisp.com/jason/family-planner) · branch `main` · TypeScript
 ## Summary
 Self-hosted family dashboard for always-on displays — calendars, chores, shopping, meals, message board, countdowns, and photo screensaver in one Docker container
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 _Source: PROJECT.md_
 # Family Planner — Project Reference
 A self-hosted family dashboard designed for always-on display (wall tablet, TV, Unraid server). Manages calendars, chores, shopping, meals, a message board, countdowns, and a photo screensaver — all in one Docker container with zero external services required.
 ---
 ## Tech Stack
 | Layer | Technology |
 |---|---|
 | **Runtime** | Node.js 22, Docker (Alpine) |
 | **Backend** | Express 4, TypeScript 5 |
 | **Database** | Node.js built-in SQLite (`node:sqlite`), WAL mode |
 | **File uploads** | Multer |
 | **Frontend** | React 18, TypeScript 5, Vite 5 |
 | **Styling** | Tailwind CSS 3, CSS custom properties (theme tokens) |
 | **Animation** | Framer Motion 11 |
 | **State / data** | TanStack Query 5, Zustand 4 |
 | **Routing** | React Router 6 |
 | **Icons** | Lucide React |
 | **Date utils** | date-fns 3 |
 | **Package manager** | pnpm (workspaces monorepo) |
 | **CI/CD** | Gitea Actions → Docker build & push to private registry |
 | **Deployment target** | Unraid (Community Applications / CLI install) |
 ---
 ## Repository Structure
 ```
 family-planner/
 ├── apps/
 │   ├── client/                     # React frontend
 │   │   └── src/
 │   │       ├── components/
 │   │       │   ├── layout/
 │   │       │   │   └── AppShell.tsx        # Sidebar, mobile drawer, page wrapper
 │   │       │   ├── screensaver/
 │   │       │   │   └── Screensaver.tsx     # Idle screensaver w/ Ken Burns slideshow
 │   │       │   └── ui/                     # Design-system primitives
 │   │       │       ├── Avatar.tsx
 │   │       │       ├── Badge.tsx
 │   │       │       ├── Button.tsx
 │   │       │       ├── Input.tsx
 │   │       │       ├── Modal.tsx
 │   │       │       ├── Select.tsx
 │   │       │       ├── Textarea.tsx
 │   │       │       └── ThemeToggle.tsx
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,82 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/inven
 repo_url: https://git.alwisp.com/jason/inven
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # inven
 **Repository:** [jason/inven](https://git.alwisp.com/jason/inven) · branch `main` · TypeScript
 ## Summary
 Single-container inventory management for Unraid — parts, assemblies, BOMs, sales/purchase orders, invoicing, and a lightweight accounting journal on SQLite
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # Inven
 Inven is a single-container inventory management system for Unraid-style deployments. It manages stocked parts, assemblies built from parts, sales orders and shipping, purchase orders and restocking, customers, vendors, and a lightweight accounting journal on top of SQLite.
 ## Current Scope
 - Parts and assemblies share one item master
 - Assemblies support bill-of-material component definitions
 - Inventory is tracked through a transaction ledger
 - Sales orders can be created and shipped
 - Purchase orders can be created and received
 - Sales orders and purchase orders are created from relational inventory line selections
 - Shipping and receiving are posted from relational order-line quantity controls
 - Sales orders support partial shipments
 - Purchase orders support partial receipts
 - Invoices are generated from shipped sales orders
 - Vendor bills are generated from received purchase orders
 - Customer and vendor payments can clear receivables and payables
 - Customer and vendor directories support the order flows
 - Low-stock and suggested reorder views help drive replenishment
 - A chart of accounts, account balances, and manual journals support the first accounting pass
 - Built-in authentication protects the app with a bootstrap admin login
 ## Stack
 - Next.js App Router
 - TypeScript
 - SQLite via `better-sqlite3`
 - Single Docker container with Next.js standalone output
 ## Quick Start
 1. Install Node.js 22 or newer.
 2. Copy `.env.example` to `.env`.
 3. Set `AUTH_SECRET`, `ADMIN_EMAIL`, and `ADMIN_PASSWORD`.
 4. Update `DATABASE_PATH` if needed.
 5. Install dependencies:
 ```bash
 npm install
 ```
 6. Start the development server:
 ```bash
 npm run dev
 ```
 7. Open `http://localhost:3000` and sign in with the bootstrap admin credentials.
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,79 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/memer
 repo_url: https://git.alwisp.com/jason/memer
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # memer
 **Repository:** [jason/memer](https://git.alwisp.com/jason/memer) · branch `main` · TypeScript
 ## Summary
 Self-hosted meme gallery with quick-share for SMS and Telegram — Dockerized masonry grid with tag search, upload, and non-destructive image rescaling
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # Memer
 A self-hosted meme gallery with quick-share for text message and Telegram. Runs as a single Docker container, designed for Unraid.
 ## Features
 - **Masonry gallery** — responsive, dark-themed grid
 - **Upload** — drag & drop or click, supports JPG/PNG/GIF/WebP (up to 100 MB)
 - **Tags** — organize with comma-separated tags, filter by tag in the gallery
 - **Search** — full-text search across titles and descriptions
 - **Quick share** — copy link, Telegram, SMS, or download from any card or detail view
 - **Non-destructive rescale** — creates a child image at a new size without touching the original
 - **Persistent** — SQLite database + image files on Docker volumes (easy to back up or export)
 ## Quick Start
 ```bash
 cp .env.example .env
 # Edit .env: set PUBLIC_URL to your domain
 docker compose up --build -d
 ```
 Open `http://localhost:3000`.
 ## Unraid Setup
 1. In Unraid, go to **Docker > Add Container** (or use Community Applications).
 2. Use the image `memer:latest` (build locally or push to a registry).
 3. Map port **3000** to your desired host port.
 4. Add two path mappings:
   - `/data/images` → `/mnt/user/appdata/memer/images`
   - `/data/db`     → `/mnt/user/appdata/memer/db`
 5. Set environment variable `PUBLIC_URL` to `https://meme.alwisp.com`.
 6. Set up your reverse proxy (Nginx Proxy Manager, Swag, etc.) to point `meme.alwisp.com` → port 3000.
 ## Environment Variables
 | Variable | Default | Description |
 |---|---|---|
 | `PUBLIC_URL` | `http://localhost:3000` | Used to build absolute share links |
 | `PORT` | `3000` | Port the server listens on |
 | `DATA_DIR` | `/data` | Root for images and DB inside the container |
 ## API
 | Method | Path | Description |
 |---|---|---|
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,65 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/mempalace
 repo_url: https://git.alwisp.com/jason/mempalace
 language: Python
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # mempalace
 **Repository:** [jason/mempalace](https://git.alwisp.com/jason/mempalace) · branch `main` · Python
 ## Summary
 Server-mode fork of MemPalace — shared Docker container on Unraid so Claude Code, Codex, and MCP clients can share one persistent AI memory palace over LAN
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # MemPalace — server-mode fork
 Local-first AI memory, deployed as a shared service across machines.
 This is a personal fork of [MemPalace](https://github.com/MemPalace/mempalace) configured for **server-mode deployment**: MemPalace runs as a Docker container (typically on Unraid) and multiple AI tools — Claude Code, Codex, Antigravity, or any MCP-compatible client — connect to a single shared palace from any machine on the network. Auto-save hooks on each client push session transcripts to the server over HTTPS with bearer auth.
 The upstream project remains local-first by design. This fork makes one deliberate trade: data crosses the LAN to a user-controlled server instead of staying on the originating machine. Privacy, verbatim storage, no-cloud, and no-telemetry properties are otherwise unchanged. See [CLAUDE.md](CLAUDE.md) for the architectural reasoning.
 ---
 ## What's in this fork
 ```
                     home LAN
   ┌───────────────────────────────────┐
   │        Unraid (always on)         │
   │   ┌────────────────────────────┐  │
   │   │ caddy :8443 (TLS + auth)   │  │
   │   │   ├─ /sse     → mcp-proxy  │  │
   │   │   └─ /ingest  → ingest API │  │
   │   │ mempalace (single process) │  │
   │   │   ├─ mcp-proxy :8765       │  │
   │   │   └─ ingest   :8766        │  │
   │   └────────────────────────────┘  │
   └───────────────────────────────────┘
        │           │           │
   ┌────┴───┐  ┌────┴───┐  ┌────┴─────┐
   │ Claude │  │ Codex  │  │ Antigrav │
   └────────┘  └────────┘  └──────────┘
 ```
 * **One palace, many clients.** Search and write target the same ChromaDB index regardless of which machine you're on.
 * **Single bearer token gates everything.** Caddy sidecar terminates TLS and enforces `Authorization: Bearer <token>` at the edge.
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,52 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/mrp-qrcode
 repo_url: https://git.alwisp.com/jason/mrp-qrcode
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # mrp-qrcode
 **Repository:** [jason/mrp-qrcode](https://git.alwisp.com/jason/mrp-qrcode) · branch `main` · TypeScript
 ## Summary
 MRP QR Code System — fabrication shop tracker with printable QR traveler cards, phone-based operator scan flow, PDF generation, and in-browser STEP viewer
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # MRP QR Code System
 A single-container, self-hosted Manufacturing Resource Planning (MRP) app built around printable QR-coded traveler cards. Designed for small fabrication shops running on an Unraid server with phone-based operators.
 ## Status
 Shipped (see [`docs/BUILD-PLAN.md`](docs/BUILD-PLAN.md)): steps 1, 2, 3, 4, 5, 6, 8.
 - **1.** Scaffold + auth (admin email/password, operator name/4-digit PIN with 12 h device session, PIN lockout, audited sessions).
 - **2.** Admin CRUD (users, machines, operation templates, projects / assemblies / parts) with content-addressed STEP / PDF / DXF / SVG file uploads.
 - **3.** Operation authoring with per-operation QR tokens (192-bit, base64url).
 - **4.** Operator scan flow — phone scan resolves `/op/scan/<token>`, single-claim enforced at DB level, Start / Pause / Done with inline QC for steps that require it, TimeLog rows for every claim.
 - **5.** PDF traveler generation — per-operation card + per-part cover sheet with the full operation list and file manifest. Printed via `pdf-lib` (no native deps).
 - **6.** Fasteners + purchase orders — per-project BOM of fasteners with unresolved-need rollups, PO lifecycle (`draft → sent → partial → received`, or `cancelled`), per-line receipt entry with auto-advance, and vendor-ready PDF downloads.
 - **8.** In-browser STEP viewer — OpenCascade (WASM, via `occt-import-js`) parses STEP/STP, `three.js` renders with OrbitControls. Thumbnails are captured from the first rendered frame, uploaded to the content-addressed file store, and displayed on the assembly parts list. No native deps, no server-side GL.
 Planned (not yet shipped): dashboard (step 7) → dedicated QC operations (9) → OpenAPI docs + backups (10).
 ## Core concepts
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,56 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/mrp
 repo_url: https://git.alwisp.com/jason/mrp
 language: TypeScript
 branch: master
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # mrp
 **Repository:** [jason/mrp](https://git.alwisp.com/jason/mrp) · branch `master` · TypeScript
 ## Summary
 CODEXIUM: modular Manufacturing Resource Planning platform — React, Express, Prisma, and SQLite with full CRM, inventory, BOM, and RBAC in one Docker container
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # CODEXIUM
 Foundation release for a modular Manufacturing Resource Planning platform built with React, Express, Prisma, SQLite, and a single-container Docker deployment.
 ## Documentation Maintenance
 - Keep [CHANGELOG.md](D:/CODING/mrp-codex/CHANGELOG.md) updated for shipped features, workflow changes, and notable operational updates.
 - Keep [README.md](D:/CODING/mrp-codex/README.md), [INSTRUCTIONS.md](D:/CODING/mrp-codex/INSTRUCTIONS.md), [STRUCTURE.md](D:/CODING/mrp-codex/STRUCTURE.md), [ROADMAP.md](D:/CODING/mrp-codex/ROADMAP.md), [SHIPPED.md](D:/CODING/mrp-codex/SHIPPED.md), and [UNRAID.md](D:/CODING/mrp-codex/UNRAID.md) aligned when changes affect their scope.
 Current foundation scope includes:
 - authentication and RBAC
 - company branding and theme settings, including startup brand-theme hydration across refresh
 - CRM customers and vendors with create/edit/detail workflows
 - CRM search, filtering, status tagging, and reseller hierarchy
 - CRM contact history, account contacts, and shared attachments
 - inventory item master, BOM, warehouse, stock-location, and stock-transaction flows
 - inventory transfers, reservations, and available-stock visibility
 - inventory SKU master builder with family-scoped sequence generation and branch-aware taxonomy management
 - staged thumbnail image attachment on inventory item create/edit workflows, with detail-page thumbnail display
 - sales quotes and sales orders with searchable customer and SKU entry
 - sales approvals, approval stamps, automatic revision history, and revision comparison on quotes and sales orders
 - purchase orders with searchable vendor and SKU entry, restricted to purchasable inventory items
 - purchase-order revision history and revision comparison across commercial and receipt changes
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,96 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/nyaa-crawler
 repo_url: https://git.alwisp.com/jason/nyaa-crawler
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # nyaa-crawler
 **Repository:** [jason/nyaa-crawler](https://git.alwisp.com/jason/nyaa-crawler) · branch `main` · TypeScript
 ## Summary
 Dockerized Nyaa.si anime torrent crawler — tracks shows, polls RSS for new episodes, and auto-downloads torrent files with a dark-themed web UI and SQLite persistence
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # nyaa-crawler
 A dockerized torrent crawler and downloader for [Nyaa.si](https://nyaa.si). Track anime shows, poll for new episodes via RSS, and automatically download `.torrent` files to a host-mounted directory.
 ## Features
 - Search Nyaa.si and add shows to a watch list
 - Automatic polling for new episodes (configurable interval, default 15 min)
 - Auto-downloads `.torrent` files to a mapped host directory
 - Track episode status: pending, auto-downloaded, or manually marked
 - Bulk-mark episodes as already downloaded
 - Minimal dark-themed web UI
 - SQLite persistence — easy to back up and migrate
 - Unraid-friendly Docker container
 ## Stack
 - **Backend**: Node.js + TypeScript + Express
 - **Frontend**: React + Vite
 - **Database**: SQLite (`better-sqlite3`)
 - **Scheduler**: `node-cron`
 - **Nyaa integration**: RSS via `fast-xml-parser`
 ## Quick Start (Docker)
 ```bash
 docker compose up -d
 ```
 Open `http://localhost:8082` in your browser.
 ## Quick Start (Development)
 ```bash
 npm install
 npm run dev
 ```
 - Client dev server: `http://localhost:5173` (proxies `/api` to `:3000`)
 - API server: `http://localhost:3000`
 ## Environment Variables
 | Variable | Default | Description |
 |---|---|---|
 | `PORT` | `3000` | HTTP port |
 | `POLL_INTERVAL_SECONDS` | `900` | Polling frequency (min 60) |
 | `TORRENT_OUTPUT_DIR` | `./data/torrents` | Where `.torrent` files are saved |
 | `DATABASE_PATH` | `./data/db.sqlite` | SQLite database path |
 ## Unraid Deployment
 ```yaml
 services:
  nyaa-watcher:
    image: your-registry/nyaa-watcher:latest
    container_name: nyaa-watcher
    restart: unless-stopped
    environment:
      - PORT=3000
      - POLL_INTERVAL_SECONDS=900
      - TORRENT_OUTPUT_DIR=/data/torrents
      - DATABASE_PATH=/data/db.sqlite
    volumes:
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,128 @@
 ---
 type: project
 status: active
 tags: [obsidian, cowork, plugin, memory]
 updated: 2026-05-27
 ---
 # obsidian-memory Plugin
 Claude Cowork plugin that uses Jason's Obsidian vault at 10.2.0.2 as persistent memory across sessions.
 ## Current status
 Plugin built and installed. Vault bootstrapped 2026-05-27. Ready for daily use — memory accumulates as sessions run.
 ## Key decisions
 - No MCP server — direct REST calls via bash/curl (simpler, fully portable in a single .plugin file)
 - API key and server hardcoded (personal plugin, not for distribution)
 - Uses `-k` flag for SSL (Obsidian Local REST API uses a self-signed cert)
 - Server: `https://10.2.0.2:27124`
 - API key: stored in skill, not to be redistributed
 - Vault layout roots at `Projects/agents/` — index → profile → memory subdirs
 ## Architecture
 ```
 obsidian-memory.plugin
 ├── .claude-plugin/plugin.json
 ├── skills/obsidian-memory/
 │   ├── SKILL.md               ← load/write/log instructions + curl patterns
 │   └── references/
 │       ├── api-reference.md   ← all curl endpoint patterns
 │       ├── vault-layout.md    ← frontmatter conventions + folder map
 │       ├── bootstrap.md       ← first-run setup procedure
 │       └── session-log-template.md
 └── README.md
 ```
 ## Vault layout
 ```
 Projects/agents/
 ├── README.md
 ├── memory/
 │   ├── profile.md
 │   ├── inbox.md
 │   ├── projects/<slug>.md
 │   ├── sessions/YYYY-MM-DD-<slug>.md
 │   ├── people/<name>.md
 │   └── decisions/YYYY-MM-DD-<slug>.md
 ```
 ## Open threads
 - [ ] Populate profile.md as facts emerge in conversations
 - [ ] Consider adding a decisions file for major project choices
 ## Log
 - 2026-05-27: Plugin built in Cowork session. Vault bootstrapped. First session logged.
 ## Known issues
 ### PATCH with `Target-Type: heading` returns invalid-target (2026-05-28)
 **Symptom:** Every `PATCH` request with `Operation: append|replace`, `Target-Type: heading`, and a `Target:` header (e.g. `Target: Current status`) returns:
 ```
 HTTP 400
 { "message": "The patch you provided could not be applied to the target content.\ninvalid-target", "errorCode": 40080 }
 ```
 This happens on **all files tested** including freshly-fetched profile.md and project files with confirmed valid heading text. The documented example from `references/api-reference.md` ("Replace a heading's content entirely") reproduces the failure exactly.
 Reading a heading via URL path (`/vault/path/file.md/heading/Heading%20Name`) **also** returns `404 Not Found` even when the heading clearly exists in the file body — so the failure is in the heading-resolution layer, not the patch-apply layer.
 **Workaround:** Use `POST` (append-to-EOF) and `PUT` (full overwrite) instead. The skill's main flow already documents POST as the default for additive entries, so this only matters when you need targeted section editing (e.g. "replace Current status" for a project file).
 **Impact:** Cannot do surgical section replacement. The project file for `unifi-access-dashboard.md` ended up with the new content appended to the bottom instead of replacing "Current status" inline — readable but less tidy.
 **To investigate:**
 - [ ] Check installed Local REST API plugin version on the vault (Obsidian → Settings → Community plugins)
 - [ ] Compare against the [coddingtonbear/obsidian-local-rest-api](https://github.com/coddingtonbear/obsidian-local-rest-api) release notes for PATCH-heading regressions
 - [ ] If recent, try downgrading; if old, try upgrading
 - [ ] Try with explicit `Target-Delimiter` header (some versions need it for top-level headings)
 - [ ] Verify the file is using LF line endings — CRLF can break heading parsing in some plugin versions
 ## Log
 - 2026-05-28: Discovered PATCH-heading bug during the unifi-access-dashboard memory update. Logged under Known issues; working around with POST/PUT.
 ### Retest after plugin upgrade 3.6 → 4.1.1 (2026-05-28)
 **Still broken.** Both failure modes reproduce identically after the upgrade:
 | Test | Result |
 |---|---|
 | `PATCH` w/ `Target-Type: heading`, `Target: Communication preferences` | HTTP 400, `invalid-target` |
 | `PATCH` w/ `Target-Type: heading`, `Target: Role` (single word, no spaces) | HTTP 400, `invalid-target` |
 | `PATCH` w/ `Target-Type: heading`, `Target: Communication%20preferences` (URL-encoded) | HTTP 400, `invalid-target` |
 | `GET /vault/.../profile.md/heading/Role` (URL-path heading read) | HTTP 404, `Not Found` |
 | `GET /vault/.../profile.md` (bare file read — sanity) | HTTP 200 ✓ |
 | **`PATCH` w/ `Target-Type: frontmatter`, `Target: updated`** | **HTTP 200 ✓** |
 **Narrowed diagnosis:** The PATCH route is healthy — `Target-Type: frontmatter` works perfectly. Only the **heading resolver** is broken. The same resolver is shared between the heading-target PATCH path and the URL-path `/heading/...` read path (both 404 on valid headings), which is consistent with a single bug in heading lookup.
 **Ruled out:**
 - ~~Plugin version (3.6 was old)~~ — 4.1.1 has the same bug
 - ~~Spaces in heading text~~ — single-word "Role" also fails
 - ~~URL encoding of `Target:` header~~ — both raw and `%20`-encoded fail
 - ~~Broken PATCH route generally~~ — frontmatter target works
 **Likely culprits (narrower now):**
 - [ ] CRLF vs LF line endings in vault files — heading parser may require LF. Files written by curl from this skill use LF, but files edited in Obsidian on Windows might get CRLF.
 - [ ] Unicode BOM at file start
 - [ ] An option in the plugin settings UI that toggles heading-mode patches
 - [ ] An upstream bug — worth opening an issue at `coddingtonbear/obsidian-local-rest-api` with this exact reproducer (it's small and easy to verify)
 **Workarounds (in order of preference):**
 1. For metadata: `Target-Type: frontmatter` works — use it for `updated`, `status`, `tags`.
 2. For additive section content: `POST` (append to EOF) — already the skill's documented default.
 3. For surgical section replacement: read the file, modify in code, `PUT` the whole thing back. Heavy-handed but reliable.
 - 2026-05-28: Plugin upgraded 3.6 → 4.1.1 to fix the PATCH-heading bug. Retest shows the bug **persists** in 4.1.1. Narrowed: `Target-Type: frontmatter` works, only `Target-Type: heading` (and the URL-path `/heading/...` read) is broken. Likely a heading-resolver bug. Workaround unchanged: POST/PUT/frontmatter-PATCH only.
@@ -0,0 +1,82 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/pnger
 repo_url: https://git.alwisp.com/jason/pnger
 language: Svelte
 branch: main
 tags:
  - repo
  - jason
  - alwisp
 updated: 2026-05-29
 ---
 # pnger
 **Repository:** [jason/pnger](https://git.alwisp.com/jason/pnger) · branch `main` · Svelte
 ## Summary
 Modern PNG editor & resizer with live preview, drag & drop, smart presets, keyboard shortcuts, and dark/light themes. TypeScript + Svelte + Sharp. Deployed on Unraid.
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # PNGer - Modern PNG Editor & Resizer
 A sleek, modern PNG editor and resizer with **live preview**, **drag & drop**, **smart presets**, **keyboard shortcuts**, and **dark/light mode theming**. Built with TypeScript and optimized for deployment as a single Docker container.
 ## ✨ Features
 - **🎨 Modern UI**: Beautiful dark/light mode for inspecting transparency.
 - **⚡ Live Preview**: Instant side-by-side comparison with file size analysis.
 - **🚀 Efficiency**: Drag & Drop upload, clipboard paste (`Ctrl+V`), and smart presets.
 - **🖼️ Precision**: Control width, height, quality, and crop positions (9 modes).
 - **📦 Reliable Deployment**: Multi-stage Docker build optimized for Unraid and Gitea.
 ## 🚀 Quick Start
 ### Docker/Unraid Deployment
 1. **Clone & Build**:
   ```bash
   git clone https://git.alwisp.com/jason/pnger.git
   cd pnger
   docker build -t pnger:latest .
   ```
 2. **Run**:
   ```bash
   docker compose up -d
   ```
 3. **Access**: `http://localhost:8080` (or your Unraid IP)
 ### Local Development
 1. **Install & Run Backend**: `cd backend && npm install && npm run dev`
 2. **Install & Run Frontend**: `cd frontend && npm install && npm run dev`
 3. **Access**: `http://localhost:5173`
 ## 📚 Documentation
 For more detailed information, please refer to:
 - **[INSTRUCTIONS.md](./INSTRUCTIONS.md)**: Technical architecture, development setup, code standards, and troubleshooting.
 - **[ROADMAP.md](./ROADMAP.md)**: Project history, sprint updates, and future feature plans.
 ## ⌨️ Keyboard Shortcuts
 - `Ctrl+V`: Paste image from clipboard
 - `Enter`: Download (when input not focused)
 - `?`: Show shortcuts help
 - `Esc`: Close dialogs
 ---
 **License**: MIT  
 **Repository**: [https://git.alwisp.com/jason/pnger](https://git.alwisp.com/jason/pnger)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,115 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/pos
 repo_url: https://git.alwisp.com/jason/pos
 language: TypeScript
 branch: main
 tags:
  - repo
  - jason
  - alwisp
 updated: 2026-05-29
 ---
 # pos
 **Repository:** [jason/pos](https://git.alwisp.com/jason/pos) · branch `main` · TypeScript
 ## Summary
 Full-stack TypeScript point-of-sale system — Android POS frontend, Node/Express API, and React admin UI packaged in a single Docker container
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # README.md
 ## Overview
 This project is a full-stack TypeScript point-of-sale (POS) system: an Android POS frontend, a Node/Express API backend, and a React admin UI, all packaged in a **single Docker container**.
 The backend exposes REST APIs for the Android app and serves the React admin UI for vendor configuration and reporting.
 ***
 ## Tech Stack
 - Node.js + TypeScript (Express or Fastify)
 - React + TypeScript (SPA)
 - SQL database (PostgreSQL in production; SQLite acceptable for local/demo)
 - Docker (single container for API + admin UI)
 ***
 ## Project Structure
 Example layout (subject to refinement):
 - `server/` – Node/TypeScript backend (Express/Fastify, Prisma, migrations)
 - `client/` – React/TypeScript admin UI
 - `android/` – Android POS app (separate repo or module)
 - `Dockerfile` – single-image build for backend + admin
 - `docker-compose.yml` – optional local DB wiring
 - `AGENTS.md`, `INSTRUCTIONS.md`, `ROADMAP.md` – agent and project docs
 ***
 ## Prerequisites
 For local (non-Docker) runs:
 - Node.js 20+ installed
 - npm or pnpm
 - PostgreSQL (or SQLite if configured)
 For Docker runs:
 - Docker Engine (and optionally Docker Compose)
 ***
 ## Environment Variables
 Backend expects:
 - `PORT` – HTTP port (default: 8080)
 - `NODE_ENV` – `development` or `production`
 - `DATABASE_URL` – connection string (e.g., Postgres)
 - `JWT_SECRET` – secret for JWT signing
 - `LOG_LEVEL` – optional (`info`, `debug`, etc.)
 Document any additional env vars you introduce in this section.
 ***
 ## Local Development (Without Docker)
 Backend:
 ```bash
 # from /server
 npm install
 npm run dev   # or equivalent, e.g. ts-node-dev / nodemon
 ```
 Admin UI:
 ```bash
 # from /client
 npm install
 npm run dev   # Vite/CRA dev server
 ```
 You can either:
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,57 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: qrknit/qrknit
 repo_url: https://git.alwisp.com/qrknit/qrknit
 language: HTML
 branch: master
 tags: [repo, qrknit]
 updated: 2026-05-29
 ---
 # qrknit
 **Repository:** [qrknit/qrknit](https://git.alwisp.com/qrknit/qrknit) · branch `master` · HTML
 ## Summary
 QRKnit: commercial QR code generator and URL shortener — create, manage, and track branded QR codes and short links
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # QRknit — URL Shortener & QR Code Generator
 A managed URL shortener with QR code generation, deep click analytics, and tag-based link organization.
 - **Multi-user** — admin account seeded from env vars; admin can create/delete/manage accounts via the UI
 - **Per-user isolation** — each user sees only their own links and tags; admin has its own isolated workspace separate from all other accounts
 - **Organizations** — group users into orgs that share link/tag visibility and pool usage quotas under a shared plan
 - **Plan tiers** — Admin / Free / Starter / Pro / Team with enforced limits on active links, monthly clicks, and analytics history window; org members inherit their org's plan
 - **Scoped tags** — tags are owned by the user who creates them; org members share a tag namespace, solo users and admins each have their own isolated namespace
 - **Deep analytics** — daily charts, referrer/device/browser/country breakdowns, hourly 7×24 heatmap, raw click CSV export
 - **Private instance** — Pro and Team plans include a dedicated private deployment on your own infrastructure
 ---
 ## 🗺 Feature Map
 ### Shipped
 | Feature area | What's included |
 |---|---|
 | **Short links** | Random & custom codes, link expiry, pinned links, one-click copy, auto-fetch page title |
 | **QR codes** | QR generation for any link or URL, logo overlay, dot-shape presets, inline thumbnail, copy to clipboard |
 | **Analytics** | Per-link daily click charts, referrer / device / browser / country breakdowns, hourly 7×24 heatmap, raw click CSV export |
 | **Tags** | Tag links for filtering; tags are scoped per user — org members share a namespace, solo users and admins each have their own |
 | **Bulk tools** | Bulk delete, bulk tag, bulk expire; CSV import & export |
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,78 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/rack-planner
 repo_url: https://git.alwisp.com/jason/rack-planner
 language: TypeScript
 branch: main
 tags: [repo, jason]
 updated: 2026-05-29
 ---
 # rack-planner
 **Repository:** [jason/rack-planner](https://git.alwisp.com/jason/rack-planner) · branch `main` · TypeScript
 ## Summary
 RackMapper: self-hosted dark-mode web app for visualizing and managing network rack infrastructure — drag-and-drop rack planner and service dependency mapper for Unraid
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # RackMapper
 A self-hosted, dark-mode web app for visualising and managing network rack infrastructure. Built for Unraid / Docker single-container deployment.
 ## Features
 ### Rack Planner (`/rack`)
 - Drag-and-drop module placement from a device palette onto U-slots
 - Drag modules between racks or reorder racks via header grip
 - Resize modules by dragging the bottom handle
 - Click any module to edit name, IP, manufacturer, model, notes, uSize
 - Port indicator dots — click any dot to open the port configuration modal
  - Set mode (Access / Trunk / Hybrid), native VLAN, tagged VLANs
  - Quick-create VLANs without leaving the modal
 - Export the full rack view as PNG
 ### Service Mapper (`/map`)
 - React Flow canvas for mapping service dependencies and traffic flows
 - Right-click canvas → add any node type at cursor position
 - Right-click node → Edit, Duplicate, Delete
 - Right-click edge → Toggle animation, change edge type, Delete
 - Double-click a node → edit label, accent colour, logical IP/Port, and rack module link
 - Logical Address mapping — assign IP and Port to any node type via metadata (stored as JSON)
 - Persistent storage — all node details and logical addresses are saved to the SQLite database
 - Auto-populate nodes from all rack modules ("Import Rack" button)
 - Connect nodes by dragging from handles; Delete key removes selected items
 - Minimap, zoom controls, snap-to-grid (15px), PNG export
 ### VLAN Management (`/vlans`)
 - Create, edit, and delete VLANs with ID, name, description, and colour
 - VLANs defined here are available in all port configuration modals
 ---
 ## Quick Start (Docker Compose)
 **1. Create a `docker-compose.yml`:**
 ```yaml
 version: '3.8'
 services:
  rackmapper:
    image: rackmapper
    build: .
    container_name: rackmapper
    ports:
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,87 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/stepview
 repo_url: https://git.alwisp.com/jason/stepview
 language: TypeScript
 branch: main
 tags:
  - repo
  - jason
  - mpm
 updated: 2026-05-29
 ---
 # stepview
 **Repository:** [jason/stepview](https://git.alwisp.com/jason/stepview) · branch `main` · TypeScript
 ## Summary
 StepView: self-hosted in-browser 3D STEP file viewer — renders .step/.stp files via OpenCascade (WASM) and three.js, deployed as a Docker container on Unraid
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 _Source: INSTALL.md_
 # StepView — Unraid Installation Guide
 This guide covers the full deployment path: building the Docker image via the Gitea CI runner, then installing and configuring the container through the Unraid Docker GUI.
 ---
 ## Table of Contents
 1. [Prerequisites](#1-prerequisites)
 2. [Build Pipeline — Gitea Actions](#2-build-pipeline--gitea-actions)
 3. [Unraid — Add the Registry](#3-unraid--add-the-registry)
 4. [Unraid — Install the Container](#4-unraid--install-the-container)
 5. [Environment Variables Reference](#5-environment-variables-reference)
 6. [Volume Paths Reference](#6-volume-paths-reference)
 7. [First-Run Steps](#7-first-run-steps)
 8. [Upgrading](#8-upgrading)
 9. [Backups](#9-backups)
 10. [Troubleshooting](#10-troubleshooting)
 ---
 ## 1. Prerequisites
 | Requirement | Notes |
 |---|---|
 | Unraid 6.12 or later | Earlier versions work but UI steps may differ slightly |
 | Gitea instance | Any version with Actions support (1.19+) |
 | Gitea Actions runner | Registered to your Gitea instance, labeled `ubuntu-latest` |
 | Docker runner image | `catthehacker/ubuntu:act-latest` (already in your workflow) |
 | `REGISTRY_USER` secret | Set in Gitea repo → Settings → Secrets |
 | `REGISTRY_TOKEN` secret | An access token with `package:write` scope on `registry.alwisp.com` |
 ---
 ## 2. Build Pipeline — Gitea Actions
 The workflow at `.gitea/workflows/docker-build.yml` runs automatically on every push to `main`. It builds the image and pushes it to:
 ```
 registry.alwisp.com/<OWNER>/stepview:latest
 ```
 ### Verify the secrets exist
 In your Gitea repository, go to **Settings → Secrets and Variables → Actions** and confirm both of these are set:
 | Secret name | Value |
 |---|---|
 | `REGISTRY_USER` | Your registry username |
 | `REGISTRY_TOKEN` | Registry access token (read/write) |
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
@@ -0,0 +1,95 @@
 ---
 type: project
 status: active
 source: git.alwisp.com
 repo: jason/storybid
 repo_url: https://git.alwisp.com/jason/storybid
 language: TypeScript
 branch: main
 tags:
  - repo
  - jason
  - stroybook
  - storybid
 updated: 2026-05-29
 ---
 # storybid
 **Repository:** [jason/storybid](https://git.alwisp.com/jason/storybid) · branch `main` · TypeScript
 ## Summary
 Self-hosted charity auction platform — live and silent auctions with offline-first PWA bidding, Socket.io real-time updates, Stripe payments, and SMS OTP auth
 ## Current status
 Active. Synced from Gitea on 2026-05-29.
 ## Documentation overview
 # Storybid
 Self-hosted charity auction platform supporting live and silent auctions in the
 same event, with offline-first PWA bidding and automatic LAN failover for
 event-night resilience.
 ## Stack
 | Layer      | Choice                                      |
 |------------|---------------------------------------------|
 | Client     | React 18 + TypeScript + Vite + Tailwind     |
 | PWA/Offline| Workbox (vite-plugin-pwa) + Dexie/IndexedDB |
 | Real-time  | Socket.io                                   |
 | Server     | Node.js + Express + TypeScript              |
 | ORM        | Prisma                                      |
 | Database   | PostgreSQL (SQLite optional for dev)        |
 | Cache/Queue| Redis (optional)                            |
 | Auth       | Email magic links + Twilio Verify SMS OTP   |
 | Payments   | Stripe Payment Element / Payment Intents    |
 | Media      | Local disk (multer) served as static files  |
 | Deploy     | Docker Compose (Unraid / Linux VM)          |
 ## Quick Start (development)
 ```bash
 # 1. Clone and install
 git clone <repo>
 cd storybid
 npm install
 # 2. Start DB + Redis
 docker compose -f docker-compose.dev.yml up -d
 # 3. Configure environment
 cp .env.example .env
 # Edit .env with your Stripe, Twilio, and SMTP keys
 # 4. Migrate database and seed demo data
 npm run db:migrate
 npm run db:seed
 # 5. Start dev servers
 npm run dev
 # Client → http://localhost:5173
 # Server → http://localhost:3001
 ```
 ## Production Deployment
 See [`ops/README.md`](./ops/README.md).
 ## Event-Night Network
 See [`ops/unifi-dns.md`](./ops/unifi-dns.md) for UniFi local DNS setup and
 WAN-failover testing.
 ## Staff Runbook
 See [`event-runbook/preflight.md`](./event-runbook/preflight.md) for the
 …(truncated — see repo)
 ## Notes
 - Project file auto-created from repo documentation.
--- a/Show More
+++ b/Show More
		`@@ -0,0 +1,3 @@`
							`241265fbe6830934a9a4ad3e69335f64a42153b663aa5b0017cb1ea1217b2bab`

							`https://echoapi.alwisp.com`
		`@@ -0,0 +1,3 @@`
							`# Heartbeat`

							`Use this folder for periodic state snapshots, compression summaries, and maintenance reports.`
		`@@ -0,0 +1,3 @@`
							`# Active Skills`

							`Store reusable agent skills here with clear triggers, versioning, and expected outputs.`
		`@@ -0,0 +1,3 @@`
							`# Archive`

							`Move completed or inactive notes here instead of deleting them when they may still be useful later.`
		`@@ -0,0 +1,3 @@`
							`# Inbox Captures`

							`Drop raw captures here before they are processed into canonical notes.`
		`@@ -0,0 +1,3 @@`
							`Bearer fb72065a05fabb28ae87c45880cc3b7aba4fd3f58e70297934145cef974e8ed8`

							`https://goldbrainapi.mpm.to`
		`@@ -0,0 +1 @@`
							`https://github.com/coddingtonbear/obsidian-local-rest-api`