RENEWA Knowledge Base

001 — Knowledge Base Setup

3 min read

001 — Knowledge Base Setup

Context

The RENEWA team works across many repos (bookish-broccoli, craftcms, CRM, config, and more) on different platforms (GitHub, Azure DevOps, Bitbucket). Each repo has its own CLAUDE.md with project-specific context, but cross-project knowledge (how systems connect, design decisions that span repos, in-flight work) had no home. Every new Claude Code session required re-explaining the same context. Non-dev team members had no way to discover this knowledge at all.

Hannes von Appen created renewa-gmbh/renewa-knowledge-base on 2026-04-15 as an Obsidian vault seeded with a rich RENEWA One outline (Home.md) and folder skeleton (Architecture/, Backend/, Frontend/, Entities/, Features/, Infrastructure/, Integrations/, Patterns/) — an excellent foundation, but missing the cross-project layer and a publishing pipeline.

Options considered

  • Dedicated GitHub repo — clean separation, auditable history, standard tooling. (Chosen.)
  • Subdirectory in bookish-broccoli — wrong scope; pollutes app-repo history.
  • Git submodule across repos — submodule overhead, friction on every clone / branch switch.
  • Subdirectory in claude/ meta-workspace — mixes repo clones with knowledge content.

Information architecture options: project-centric, topic-centric, hybrid. Chose project-namespaced (projects/<name>/<sub-folder>/) so each project owns its taxonomy. Hannes’s RENEWA One sub-folders (Architecture, Backend, etc.) become RENEWA One’s taxonomy under projects/renewa-one/; other projects can adopt different sub-folders as needed. Cross-cutting topics live in topics/.

Static-site generator: Quartz (chosen) for native Obsidian feature support (wiki-links, graph view, backlinks, full-text search).

Repo name: renewa-knowledge-base (Hannes’s choice — descriptive and implementation-agnostic).

Reader access: Cloudflare Pages + Cloudflare Zero Trust Access (chosen) so non-dev team members can read the site without a GitHub seat (saves ~21 EUR / seat / month at scale).

Authoring workflow: direct push to main (chosen). Content is additive, merge conflicts rare. Process overhead would kill contribution momentum.

Update mechanism: semi-automatic during dev sessions + periodic sweep (chosen). Fully automatic is fragile today; explicit-only requires too much human effort.

Decision

renewa-gmbh/renewa-knowledge-base (internal visibility), project-namespaced layout, Quartz published to wiki.renewa.de behind Cloudflare Zero Trust, direct push to main, semi-automatic + periodic sweep updates by Claude with human review, Karpathy three-layer model: raw/ (human-curated immutable sources), content/ (Claude-maintained synthesized pages), CLAUDE.md (schema).

Consequences

  • Non-dev team members read at wiki.renewa.de without GitHub seats (cost savings)
  • Every project repo’s CLAUDE.md links to the knowledge base
  • Claude proposes knowledge-base updates at natural breakpoints (PR merged, architecture change); a periodic sweep catches drift
  • Quartz updates pulled via npx quartz update periodically
  • Hannes’s RENEWA One folders moved into content/projects/renewa-one/ via git mv (history preserved, wiki-links unaffected because they use bare-name resolution)

Participants

Martin von Schledorn (design lead), Hannes von Appen (initial repo setup), Claude (synthesis). 2026-04-13 to 2026-04-16.

Graph View

Backlinks