7Mind Brain

STRUCTURE

5 min read

Summary: The agent-contract for this wiki. Read this before reading or writing any page. Sources: initial architecture design, 2026-05-15 Last updated: 2026-05-15

STRUCTURE.md — 7Mind Company Wiki

This file is the single source of truth for how this wiki is organized and how agents should interact with it. Every agent that reads or writes to this wiki must read this file first.

1. Purpose

This wiki is the shared “second brain” for 7Mind’s engineering system. It gives AI agents (Claude Code instances running inside individual repos) the cross-repo context they cannot derive from a single codebase alone.

Primary readers: AI agents running in 7Mind repos. Secondary readers: human engineers who need a quick orientation. Primary authors: AI agents, after significant changes to their repo. Reviewer: Nikolas Haag (human review, periodic).

The wiki complements code — it does not duplicate it. Never paste code here. Never paste PR descriptions here. The wiki captures what the code cannot explain on its own: how repos connect, why decisions were made, what the product is, and how the company operates.

2. Folder Map

All wiki content lives in content/ within the brain repo. When you clone the repo, the structure looks like this:

brain/                    git repo root
├── CLAUDE.md             agent instructions (Claude Code reads this automatically)
├── content/              all wiki pages live here
│   ├── STRUCTURE.md      this file — read it first
│   ├── log.md            append-only log of structural wiki changes
│   │
│   ├── business/         business intelligence layer
│   │   ├── product/      what 7Mind is, its markets, strategic direction
│   │   ├── brand/        visual identity, voice, tone
│   │   ├── customers/    B2C, B2B, B2B2C segment notes
│   │   └── processes/    internal workflows (release, oncall, etc.)
│   │
│   └── tech/             technical intelligence layer
│       ├── repos/        one file per repo — the most agent-critical section
│       ├── packages/     one file per shared NPM package
│       ├── infrastructure/ GCP, Cloudflare, Terraform, GitHub Actions
│       └── integrations/ cross-repo connection patterns
│
└── quartz/               Quartz SSG (builds brain.6mind.de — do not edit)

When you open the wiki in Obsidian, open the vault at brain/content/, not brain/.

Paths in wiki pages are always relative to the vault root (content/). A link like [[elixir-backend]] resolves to content/tech/repos/elixir-backend.md.

3. Frontmatter Schema

Every page begins with YAML frontmatter followed by three required header fields, then a horizontal rule, then content.

Required header fields (after frontmatter, before content)

**Summary**: one sentence describing this page
**Sources**: where the information came from
**Last updated**: YYYY-MM-DD

Frontmatter by page type

Repo note (tech/repos/*.md):

---
type: repo-note
repo: <exact-github-repo-slug>
stack: [language, framework, ...]
owner-repo: <repo-slug>
last-updated: YYYY-MM-DD
tags: []
status: active          # active | archived | experimental
---

Package note (tech/packages/pkg-*.md):

---
type: package-note
package: @7mind/<package-name>
repo: <source-repo-slug>
owner-repo: <source-repo-slug>
last-updated: YYYY-MM-DD
tags: [npm, shared]
---

Infrastructure note (tech/infrastructure/*.md):

---
type: infra-note
last-updated: YYYY-MM-DD
tags: [gcp | cloudflare | github-actions | terraform]
---

Business note (business/**/*.md):

---
type: product | brand | customer | process
last-updated: YYYY-MM-DD
tags: []
---

Index file (*-index.md):

---
type: index
last-updated: YYYY-MM-DD
---

4. Naming Conventions

ThingRuleExample
All fileslowercase-with-hyphens.mdelixir-backend.md
Repo notesmatch GitHub repo slug exactlyapi-contracts.md
Package notespkg-<npm-name>.mdpkg-design-tokens.md
Index files<folder>-index.mdtech-index.md
Tagslowercase, hyphenatedb2b2c, github-actions

Basenames must be unique across the entire vault. Obsidian wiki-links resolve by basename only. If two files share a basename, links break silently. Check uniqueness before creating a new file.

Always use [[basename]] syntax for internal links. Never use relative paths.

Good: See [[flutter-app]] for the mobile repo.
Bad:  See [flutter-app](../tech/repos/flutter-app.md).

When linking to a specific section: [[basename#section-heading|Section Heading]].

6. Agent Write Protocol

When to update the wiki

Update your repo note (tech/repos/<your-repo>.md) after merging a change that affects any of:

  • The repo’s purpose or primary behavior
  • Its stack (new major dependency, language change, framework upgrade)
  • Its deployment target or pipeline
  • Its external service dependencies
  • Its integration points with other repos

Do NOT update after every commit. One wiki update per meaningful architectural or behavioral shift is the right cadence.

Which notes to update

  1. Your owner-repo note (always).
  2. Any tech/integrations/ note that describes a connection your change affects.
  3. Any tech/packages/ note if you published or significantly changed a shared package.

Do not edit business layer notes unless you have been explicitly asked to by a human.

Commit message format

wiki: update <repo-slug> — <short reason>

Examples:

wiki: update elixir-backend — added Stripe webhook handler
wiki: update flutter-nuxt — updated auth flow, frontend now calls new /v2/session endpoint

Do not

  • Create new top-level folders (business/, tech/) without human approval.
  • Add secrets, tokens, passwords, or environment variable values.
  • Paste raw code blocks — reference file paths instead.
  • Duplicate information already in the codebase. Link to it.
  • Use em dashes anywhere in any page.

7. Repo Note Template

Use this template for every new file in tech/repos/. Fill in what you know; leave sections as TBD if unknown.

---
type: repo-note
repo: <repo-slug>
stack: []
owner-repo: <repo-slug>
last-updated: YYYY-MM-DD
tags: []
status: active
---
 
**Summary**: <one sentence>
**Sources**: direct code inspection
**Last updated**: YYYY-MM-DD
 
---
 
## Purpose
 
What this repo does, what problem it solves, who uses it.
 
## Stack
 
Languages, frameworks, and major dependencies worth noting.
 
## Key Files / Entry Points
 
- `path/to/file` — what it does
 
## Deployment
 
How and where this deploys. Staging vs production environment. GitHub Actions workflow name. Target (GCP service, Cloudflare Pages, etc.).
 
## Dependencies
 
**External services**: third-party APIs or SDKs this repo calls.
**Internal**: other repos or packages this consumes — use [[wiki-links]].
 
## Integration Points
 
What consumes this repo's output: other internal repos, CDN, mobile clients, etc.
 
## Conventions
 
Non-obvious patterns an agent should know before editing: naming rules, gotchas, required env vars, local setup quirks.
 
## Agent Change Log
 
Append one line after each significant change. Do not edit past entries.
Format: `YYYY-MM-DD — what changed and why`

Graph View

Backlinks