Agent Landing

You are an AI agent working in levander's Obsidian vault.

This note is your map. Read it first, then follow the links to what you need.

Vault Purpose

This is a personal knowledge base covering three active software projects and a full dev-environment reference. The owner (levander / Andras) is a developer who works with AI agents daily — everything here is written to be agent-friendly.

Vault Structure

levandor_obsidian/
├── Agent Landing.md          ← you are here
├── projects/
│   ├── alpiq-bess/           ← Rust/Python BESS platform (Alpiq)
│   ├── facekom/              ← Enterprise KYC/eKYC platform (TechTeamer)
│   │   └── investigations/   ← ticket-level deep dives
│   └── levandor-crm/         ← Personal CRM (React + Supabase)
└── .agents/                  ← AgentOps artifacts (not vault content)

Projects — Where to Look

Project	Entry Point	Agent Context	Key Tags
Alpiq BESS (Mando)	Alpiq BESS	BESS Agent Context	#alpiq, #bess
FaceKom	FaceKom	FaceKom Agent Context	#facekom
Levandor CRM	levandor-crm	CRM Agent Context	#levandor, #crm

Always load the Agent Context note for a project before doing any work in it. These contain architecture, conventions, and critical knowledge you need.

Where to Write

You want to…	Write it in…
Add project knowledge (architecture, conventions, decisions)	projects/<project>/ — link from the project’s main note
Investigate a specific ticket or bug	projects/<project>/investigations/ (create the folder if missing)
Add agent context for a project	projects/<project>/agent-context*.md — tag with #agent-context
Create a daily note	Vault root, named YYYY-MM-DD.md
Create a debugging log	projects/<project>/debugging-log*.md

Diagrams — Mermaid Guidelines

This vault uses Mermaid diagrams rendered natively by Obsidian. Follow these rules when creating or editing diagrams, and progressively disclose detail so readers can drill in at their own pace.

Progressive Disclosure Pattern

Wrap diagrams in foldable callouts so they don’t dominate the page. Use collapsed (-) by default for supplementary diagrams, expanded (+) only for the primary diagram of a note.

> [!abstract]- System Architecture
> 
> ```mermaid
> graph TD
>     A --> B --> C
> ```

When a topic has multiple levels of detail, nest them:

1. Top-level callout — high-level overview diagram (collapsed)
2. Subsection callouts inside — detailed breakdowns per component (collapsed)

> [!abstract]- Architecture Overview
> 
> ```mermaid
> graph TD
>     Frontend --> API --> DB
> ```
>
> > [!example]- Frontend detail
> > ```mermaid
> > graph LR
> >     React --> Router --> Pages
> > ```
>
> > [!example]- API detail
> > ```mermaid
> > graph LR
> >     Express --> Auth --> Routes
> > ```

When to Use Diagrams

Use a diagram when…	Diagram type
Showing system/service topology	graph TD or graph LR
Documenting a workflow or process	flowchart TD
Mapping state transitions	stateDiagram-v2
Showing a timeline or sequence	sequenceDiagram
Categorizing concepts	mindmap
Comparing phases or milestones	gantt

Diagram Style Rules

• Dark-theme friendly — use muted fill colors (#2d2d2d, #264653, #3d2020) with light text (#fff). Avoid bright backgrounds.
• Label nodes clearly — use <br/> for line breaks inside node labels, <b> for emphasis, <i> for annotations.
• Keep it scannable — max ~8-10 nodes per diagram. If it’s bigger, split into multiple progressive-disclosure layers.
• Link to notes — reference vault notes in labels using [[Note Name]] syntax where it helps navigation.
• No orphan diagrams — every diagram must live inside a callout with a descriptive title. Never put a bare mermaid block at the top level of a note.
• Callout type conventions:
  • [!abstract] — structural overviews (architecture, directory trees)
  • [!example] — component-level detail diagrams
  • [!info] — flowcharts and routing/decision diagrams
  • [!note] — sequence diagrams and timelines

Minimal Example

> [!abstract]- Data Flow
> 
> ```mermaid
> graph LR
>     Input["User Input"] --> Validate["Validation"]
>     Validate --> Store["Supabase"]
>     Store --> Cache["TanStack Query"]
>     Cache --> UI["React Component"]
>     style Input fill:#264653,stroke:#2a9d8f,color:#fff
>     style Store fill:#2d2d2d,stroke:#888,color:#fff
> ```

Writing Conventions

• Frontmatter is required on every note — at minimum include tags.
• Wikilinks ([[Note Name]]) for all internal references — never relative markdown links.
• Tag with the project name (#alpiq, #facekom, #levandor) so notes are filterable.
• Agent context notes get the #agent-context tag and an alias ending in “Agent Context”.
• MOC notes (maps of content) get the #moc tag.
• Notes that serve as indexes or entry points should use callouts to orient the reader.

Tags Reference

Tag	Meaning
#agent-context	Dense reference designed for AI agent onboarding
#moc	Map of Content — index note linking related notes
#alpiq, #bess	Alpiq BESS / Mando project
#facekom	FaceKom / vuer project
#levandor, #crm	Levandor CRM project
#quick-reference	Cheat-sheet style note

What NOT to Do

• Do not write into .obsidian/ or .agents/ — these are managed by Obsidian and AgentOps respectively.
• Do not create README.md files — this vault uses Obsidian notes, not GitHub conventions.
• Do not use standard markdown links ([text](path)) for internal vault links — use wikilinks.
• Do not create notes without frontmatter tags.