parking_solution/wiki/CLAUDE.md

Parking System Wiki — Schema & Maintenance Guide

This directory is an LLM-maintained wiki (an Obsidian vault). It follows the "LLM Wiki" pattern: raw sources are immutable inputs; the wiki is a persistent, compounding, interlinked knowledge base that the LLM writes and maintains. The human curates sources and asks questions; the LLM does all bookkeeping.

Layers

• raw/ — immutable source documents. Read from, never modify. Source of truth. (Windows downloads sometimes leave :Zone.Identifier metadata companions — delete them.)
• wiki pages — everything else under this directory. LLM-owned: summaries, entity pages, concept pages, decision records, the overview, the synthesis.
• this file (CLAUDE.md) — the schema. How the wiki is structured and the workflows to follow. Co-evolve it as conventions change.

Directory layout

wiki/
├── CLAUDE.md          # this schema
├── index.md           # content catalog — every page, one line each, by category
├── log.md             # append-only chronological record (ingests, queries, lints)
├── overview.md        # the top-level synthesis / entry point to the wiki
├── raw/               # immutable sources
├── sources/           # one summary page per raw source
├── entities/          # concrete things: devices, components, technologies, parties
├── concepts/          # ideas, patterns, constraints, threat-model elements
└── decisions/         # standing decisions (settled) and open questions (unsettled)

Page conventions

• Filenames: kebab-case, .md. Title = # H1 matching the topic.
• Frontmatter (YAML) on every wiki page:

  ---
  type: source | entity | concept | decision | overview | reference
  tags: [parking, ...]
  sources: [parking-system-architecture]   # raw source slugs (omit/[] if not source-derived)
  updated: 2026-06-14
  status: settled | open      # decisions only
  ---
  

• Links: use Obsidian [[wikilinks]] liberally — link entities, concepts, and decisions wherever they're mentioned. A link to a page that doesn't exist yet is fine; it marks a page worth writing. Prefer [[page-name]] or [[page-name|alias]].
• Citations: when a claim comes from a source, reference it, e.g. (see [[parking-system-architecture]] §6). Keep section numbers when the source has them.
• Keep pages focused and atomic. One entity/concept per page. Cross-link rather than duplicate.

Workflows

Ingest (new source dropped in raw/)

1. Read the source fully.
2. Write/update a summary in sources/<slug>.md (key takeaways + section map).
3. Create or update entity pages for every concrete thing it describes.
4. Create or update concept pages for every pattern/constraint/idea.
5. Update decisions/ — record settled decisions and open questions.
6. Update overview.md synthesis if the big picture changed.
7. Update index.md (add/adjust catalog lines).
8. Append a log.md entry: ## [YYYY-MM-DD] ingest | <Source Title>.
9. Note any contradictions with existing pages explicitly on the affected page.

Query (a question against the wiki)

1. Read index.md to locate relevant pages, then drill in.
2. Synthesize an answer with [[links]] and source citations.
3. If the answer is durable (a comparison, analysis, discovered connection), file it back as a new page and catalog it. Append a query line to log.md.

Lint (health check)

Look for: contradictions between pages, stale claims superseded by newer sources, orphan pages (no inbound links), concepts mentioned but lacking a page, missing cross-references, and data gaps worth a web search. Report findings; suggest next sources/questions. Append a lint line to log.md.

Log convention

Append-only. Each entry starts with a parseable prefix so grep "^## \[" log.md | tail -5 works:

## [2026-06-14] ingest | Parking System — Architecture & Design Notes

Style

• Faithful to sources. Flag uncertainty and open questions rather than papering over them.
• This domain (a parking-management system) is offline-first and fraud/threat-model driven — those two forces shape most content; keep them front of mind when synthesizing.