admin/my-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-04-14 14:01:52

Browse Source
This commit is contained in:
admin
2026-04-14 14:01:53 +08:00
parent 3ea5708f6c
commit b388511dd7
130 changed files with 57616 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

276
.obsidian/plugins/skills/tutor-setup/references/codebase-templates.md vendored Normal file
View File

@@ -0,0 +1,276 @@
# Codebase Mode — Templates Reference
## Vault Folder Structure
```
StudyVault/
00-Dashboard/ # MOC + Quick Reference + Getting Started
01-Architecture/ # System overview, request flow, data flow
02-<Module1>/ # Per-module notes
03-<Module2>/
...
NN-DevOps/ # Build, deploy, CI/CD, env config
NN+1-Exercises/ # Onboarding exercises
```
## Dashboard MOC Template
```markdown
---
module: dashboard
path: 00-Dashboard
keywords: MOC, onboarding, architecture, <project-name>
---
# <Project Name> — Onboarding Map
#dashboard #onboarding
## Architecture Overview
- Pattern: <architectural pattern>
- Tech stack: <languages, frameworks, key libraries>
- → [[System Architecture]]
- → [[Request Flow]]
## Module Map
| Module | Purpose | Key Entry Point | Notes |
|--------|---------|-----------------|-------|
| <name> | <1-line purpose> | `<path>` | [[Module Note]] |
## API Surface
| Method | Path / Command | Module | Notes |
|--------|---------------|--------|-------|
| GET | `/endpoint` | <module> | [[API Note]] |
## Getting Started
1. Prerequisites: ...
2. Install: `<install command>`
3. Configure: copy `.env.example` → `.env`
4. Run: `<run command>`
5. Test: `<test command>`
## Tag Index
| Tag | Description | Rule |
|-----|-------------|------|
| `#arch-*` | Architecture concepts | Top-level pattern tags |
| `#module-*` | Module-specific | One per module |
## Onboarding Path
> Recommended reading order for new developers:
1. [[System Architecture]] — big picture
2. [[Request Flow]] — how a request moves through the system
3. [[Module A]] → [[Module B]] → ... — module deep dives
4. [[Exercises]] — hands-on practice
```
## Quick Reference Template
```markdown
---
module: dashboard
path: 00-Dashboard
keywords: quick-reference, commands, setup
---
# Quick Reference
#dashboard #quick-reference
## Key Commands
| Action | Command |
|--------|---------|
| Install deps | `<command>` |
| Run dev | `<command>` |
| Run tests | `<command>` |
| Build | `<command>` |
| Lint | `<command>` |
## Environment Setup
1. ...
## Important File Locations
| File / Dir | Purpose |
|------------|---------|
| `<path>` | <description> |
## Common Debugging
| Symptom | Where to Look | → Note |
|---------|---------------|--------|
| <problem> | `<file/log>` | [[Module Note]] |
```
## Module Note Template
```markdown
---
module: <module-name>
path: <relative-path-from-project-root>
keywords: <3-5 English keywords>
---
# <Module Name> (<Importance: ★~★★★>)
#module-<name> #<pattern-tag>
## Purpose
<1-3 sentences: what this module does and why it exists>
## Key Files
| File | Role |
|------|------|
| `<relative-path>` | <description> |
## Public Interface
| Export | Type | Description |
|--------|------|-------------|
| `<name>` | function/class/endpoint | <what it does> |
## Internal Flow
```text
<ASCII diagram showing data/control flow within this module>
```
## Dependencies
| Direction | Module / Service | Via |
|-----------|-----------------|-----|
| **Uses** | <dependency> | `<import/call>` |
| **Used by** | <dependent> | `<import/call>` |
## Configuration
| Env Var / Config Key | Purpose | Default |
|---------------------|---------|---------|
| `<VAR>` | <description> | `<default>` |
## Testing
- Run: `<test command for this module>`
- Pattern: <unit/integration/e2e>
- Coverage notes: ...
## Related Notes
- [[Other Module]]
- [[Architecture Note]]
```
## API Note Template
```markdown
---
module: <module-name>
path: <relative-path>
keywords: API, <endpoint-keywords>
---
# <Endpoint Group> API
#api-<group> #module-<name>
## Endpoints
| Method | Path | Auth | Description |
|--------|------|------|-------------|
| GET | `/path` | required | <description> |
## Request / Response
### <Endpoint Name>
**Request**:
```json
{
"field": "type — description"
}
```
**Response (success)**:
```json
{
"field": "type — description"
}
```
**Error cases**:
| Status | Condition | Response |
|--------|-----------|----------|
| 400 | <condition> | `{ "error": "..." }` |
## Related Notes
- [[Module Note]]
- [[Other API Note]]
```
## Onboarding Exercise Template
```markdown
---
module: exercises
path: <NN+1>-Exercises
keywords: practice, onboarding, <topic>
---
# <Topic> — Onboarding Exercises
#practice #onboarding #module-<name>
## Related Modules
- [[Module Note 1]]
- [[Module Note 2]]
---
## Exercise 1 — Code Reading [trace]
> Trace what happens when <specific trigger>. List the files and functions involved in order.
> [!answer]- View Answer
> 1. `<file>` → `<function>` — <what happens>
> 2. `<file>` → `<function>` — <what happens>
> 3. ...
---
## Exercise 2 — Configuration [config]
> How would you change <specific setting>? Which files need modification?
> [!answer]- View Answer
> - File: `<path>`
> - Change: <description>
> - Related env var: `<VAR>`
---
## Exercise 3 — Debugging [debug]
> If <symptom> occurs, where would you look first? Describe your investigation steps.
> [!answer]- View Answer
> 1. Check `<file/log>` for ...
> 2. Verify `<config>` is ...
> 3. Common cause: ...
---
## Exercise 4 — Extension [extend]
> How would you add <new feature/endpoint>? Describe the files you'd create or modify.
> [!answer]- View Answer
> 1. Create `<path>` — <purpose>
> 2. Modify `<path>` — <what to add>
> 3. Add test in `<path>` — <what to test>
> 4. Register in `<path>` — <wiring>
---
> [!summary]- 학습 포인트 요약
> | Topic | Key Takeaway |
> |-------|-------------|
> | <topic> | <insight> |
```
## Formatting Rules
- `[[wiki-links]]` for all cross-references
- `> [!tip]`, `> [!important]`, `> [!warning]` callouts for key information
- ASCII diagrams for flows, architecture, and module interactions
- Tables over prose for structured information
- **Bold** for critical terms and file paths in descriptions
- Code blocks with language hints for commands and snippets
- **Localization**: Fold callout labels (e.g., `View Answer`) should match team language. Korean: `정답 보기`, English: `View Answer`

96
.obsidian/plugins/skills/tutor-setup/references/codebase-workflow.md vendored Normal file
View File

@@ -0,0 +1,96 @@
# Codebase Mode — Onboarding Vault Workflow
> Generates a StudyVault that helps new developers understand and navigate a source code project.
> All scanning and output MUST stay within CWD.
## Phase C1: Project Exploration
1. **Scan project structure**: `Glob` for source files, config files, test files. Build a file tree.
2. **Identify tech stack**: Detect languages, frameworks, build tools, package managers from config files.
3. **Read key files**: README, CONTRIBUTING, entry points (`main.*`, `index.*`, `app.*`), config files.
4. **Map project layout**: Record directory purposes (e.g., `src/`, `test/`, `config/`, `scripts/`).
5. **Present findings** to user for confirmation before proceeding.
## Phase C2: Architecture Analysis
1. **Identify architectural patterns**: layered, hexagonal, microservice, monolith, serverless, etc.
2. **Map module boundaries**: Which directories/packages form distinct modules or domains?
3. **Trace request flow**: For a typical request (HTTP, event, CLI), trace the path through the code.
4. **Identify key abstractions**: Interfaces, base classes, shared utilities, middleware, interceptors.
5. **Map dependencies**: Internal module dependencies + external service integrations.
6. **Document data flow**: How data enters, transforms, persists, and exits the system.
7. **Build architecture summary**: Create a concise diagram (ASCII) + description for the vault.
## Phase C3: Tag Standard
Define tag vocabulary before creating notes:
- **Format**: English, lowercase, kebab-case
- **Categories**: `#arch-*` (architecture), `#module-*` (modules), `#pattern-*` (patterns), `#config-*` (config), `#api-*` (API), `#test-*` (testing)
- **Registry**: Only registered tags allowed. Present registry to user for approval.
## Phase C4: Vault Structure
Create `StudyVault/` per [codebase-templates.md](codebase-templates.md) folder structure:
- `00-Dashboard/` — MOC, Quick Reference, Getting Started
- `01-Architecture/` — System overview, request flow, data flow
- `02-XX/` through `NN-XX/` — One folder per module/domain
- `NN+1-DevOps/` — Build, deploy, CI/CD, environment config
- `NN+2-Exercises/` — Onboarding exercises
## Phase C5: Dashboard Creation
Create `00-Dashboard/` with:
### MOC (Map of Content)
- **Architecture Overview**: Link to architecture notes
- **Module Map**: Table of all modules with purpose + links
- **API Surface**: Summary of endpoints/commands/events
- **Getting Started**: Setup instructions, dev workflow, key commands
- **Tag Index**: Tag registry with hierarchy rules
- **Onboarding Path**: Recommended reading order for new developers
### Quick Reference
- Key commands (build, test, deploy, lint)
- Environment setup steps
- Common debugging tips
- Important file locations
## Phase C6: Module Notes
One note per module/domain. Per [codebase-templates.md](codebase-templates.md). Key rules:
- YAML frontmatter: `module`, `path`, `keywords` (MANDATORY)
- **Purpose**: What this module does (1-3 sentences)
- **Key Files**: Table of important files with descriptions
- **Public Interface**: Exported functions/classes/endpoints
- **Internal Flow**: How data moves through this module (ASCII diagram)
- **Dependencies**: What this module depends on + what depends on it
- **Configuration**: Relevant env vars, config keys
- **Testing**: How to run tests for this module, test patterns used
- **Related Notes**: Links to related modules and architecture notes
For API-heavy modules, create separate API notes per [codebase-templates.md](codebase-templates.md).
## Phase C7: Onboarding Exercises
Create exercises that guide new developers through the codebase. Per [codebase-templates.md](codebase-templates.md).
- **Code Reading**: "Trace what happens when X occurs" — answer in fold callout
- **Configuration**: "How would you change Y?" — answer with file paths + snippets
- **Debugging**: "Where would you look if Z breaks?" — answer with investigation steps
- **Extension**: "How would you add feature W?" — answer with architectural approach
- Minimum 5 exercises per major module
- All answers use `> [!answer]- <label>` fold callout (localize label to team language, e.g., "정답 보기" for Korean, "View Answer" for English)
## Phase C8: Interlinking
1. `## Related Notes` on every module note
2. MOC links to every module note + exercise file
3. Cross-link modules that depend on each other
4. Architecture notes reference specific module implementations
5. Exercises reference the modules they cover
6. Quick Reference links to relevant module notes
## Phase C9: Self-Review (MANDATORY)
Verify against [quality-checklist.md](quality-checklist.md) **Codebase Mode** section. Fix and re-verify until all checks pass.

106
.obsidian/plugins/skills/tutor-setup/references/quality-checklist.md vendored Normal file
View File

@@ -0,0 +1,106 @@
# Quality Checklist — Self-Review
Before reporting completion, verify every item in the relevant mode's section. Fix and re-verify if any check fails.
---
## Document Mode
### Source Traceability
- [ ] Every source file's content verified (not filename-based assumption)
- [ ] Source content mapping table built and verified in Phase D1
- [ ] Every `source_pdf` frontmatter matches verified mapping
- [ ] Non-academic files excluded and documented
- [ ] Missing sources marked as `원문 미보유`
- [ ] Non-core topic policy documented in MOC
### Coverage
- [ ] Every topic from Phase D2 checklist has a concept note
- [ ] Every enumerated category member has its own note
- [ ] No source topic missing or underrepresented
### Tags
- [ ] All tags: English kebab-case, from registry only
- [ ] Tag Index includes hierarchy rules
- [ ] Detail tags co-attached with parent domain tags
### Structure & Formatting
- [ ] Every note has YAML frontmatter: `source_pdf`, `part`, `keywords`
- [ ] Every concept note has comparison table + exam/test patterns section
- [ ] Process/flow topics have ASCII diagrams
- [ ] Notes are concise (tables > prose)
- [ ] Simplified statements include exception caveats
### Dashboard
- [ ] MOC: Topic Map + Practice Notes + Study Tools + Tag Index + Weak Areas + Non-core Policy
- [ ] MOC links to every concept note AND practice note
- [ ] Weak Areas link to `→ [[note]]` AND `→ [[Exam Traps]]`
- [ ] Exam Traps exists with per-topic fold callouts and bidirectional links
### Quick Reference
- [ ] All key formulas and condition expressions included
- [ ] Every section links to concept note via `→ [[Note]]`
### Practice — Active Recall
- [ ] Every topic folder has practice file (8+ questions)
- [ ] All answers use `> [!answer]- 정답 보기` fold — never immediately visible
- [ ] Key Patterns: `> [!hint]-` fold; Pattern Summary: `> [!summary]-` fold
- [ ] `## Related Concepts` with backlinks in every practice file
- [ ] Question type diversity: ≥60% recall, ≥20% application, ≥2 analysis per file
### Interlinking
- [ ] Every concept note has `## Related Notes`
- [ ] `[[wiki-links]]` for all cross-references
- [ ] Siblings reference each other; concept ↔ practice cross-linked
- [ ] Exam Traps ↔ Concept notes bidirectionally linked
### CWD Boundary
- [ ] No source files accessed outside CWD
- [ ] No absolute file paths in notes or frontmatter
- [ ] External URLs accessed only via WebFetch, not file paths
---
## Codebase Mode
### Project Coverage
- [ ] All major modules/domains identified and documented
- [ ] Architecture pattern documented with ASCII diagram
- [ ] Request flow traced end-to-end
- [ ] Data flow documented (input → processing → persistence → output)
- [ ] External dependencies and integrations listed
### Module Completeness
- [ ] Every module has a dedicated note with YAML frontmatter (`module`, `path`, `keywords`)
- [ ] Every module note includes: Purpose, Key Files, Public Interface, Internal Flow, Dependencies
- [ ] Configuration section lists relevant env vars / config keys
- [ ] Testing section includes commands and patterns
### Tags
- [ ] All tags: English kebab-case, from registry only
- [ ] Tag Index in MOC with hierarchy rules
- [ ] Tags cover: `#arch-*`, `#module-*`, `#pattern-*`, `#api-*`
### Dashboard
- [ ] MOC: Architecture Overview + Module Map + API Surface + Getting Started + Tag Index + Onboarding Path
- [ ] MOC links to every module note and exercise file
- [ ] Quick Reference: key commands, env setup, file locations, debugging tips
- [ ] Getting Started section is actionable (copy-paste commands)
### Onboarding Exercises
- [ ] Minimum 5 exercises per major module
- [ ] Exercise types: code reading (trace), configuration, debugging, extension
- [ ] All answers use `> [!answer]- 정답 보기` fold callout
- [ ] Exercises reference relevant module notes via `[[wiki-links]]`
### Interlinking
- [ ] Every module note has `## Related Notes`
- [ ] `[[wiki-links]]` for all cross-references
- [ ] Dependent modules cross-linked bidirectionally
- [ ] Architecture notes reference specific module implementations
- [ ] Exercises link back to the modules they cover
### CWD Boundary
- [ ] No references to files outside the project directory
- [ ] All file paths in notes are relative to project root
- [ ] No hardcoded absolute paths

213
.obsidian/plugins/skills/tutor-setup/references/templates.md vendored Normal file
View File

@@ -0,0 +1,213 @@
# Templates Reference
## Vault Folder Structure
```
StudyVault/
00-Dashboard/ # MOC + cheat sheets + Exam Traps
01-<Topic1>/ # Concept notes per domain
02-<Topic2>/
...
NN-문제풀이/ (or Practice/)
```
## Dashboard MOC Template
```markdown
---
source_pdf: <list all source files>
part: <part numbers or "all">
keywords: MOC, study map, <subject>
---
# <Subject> Study Map
#dashboard #<subject-tag>
## Overview
- Exam/certification info (if applicable)
- Domain weights or topic importance
## Topic Map
| Section | Source | Notes | Status |
|---------|--------|-------|--------|
| Topic 1 | Part 1 | [[Note 1]], [[Note 2]] | [ ] |
## Practice Notes
| 문제셋 | 문항 수 | 링크 |
|--------|---------|------|
| Topic 1 | N문제 | [[Topic 1 Practice]] |
## Study Tools
| 도구 | 설명 | 링크 |
|------|------|------|
| Exam Traps | 시험 함정/오답 포인트 모음 | [[Exam Traps]] |
| Quick Reference | 전체 치트시트 | [[빠른 참조]] |
## Tag Index
| Tag | 관련 주제 | 규칙 |
|-----|-----------|------|
| `#tag-name` | Brief description | 상위/도메인/세부/기법/유형 |
> **태그 규칙**: <1-line summary of hierarchy rule>
## Weak Areas
- [ ] Area needing review → [[Relevant Note]] → [[Exam Traps]]
## Non-core Topic Policy
| Source | Content | Handling |
|--------|---------|----------|
| <file> | <description> | **Excluded** — reason |
```
## Quick Reference Template
- **Every section heading MUST include `→ [[Concept Note]]` link**
- One-line summary table per concept/term
- Grouped by category
- All key formulas and condition expressions
- "Must-know formulas/patterns" section at bottom with `→ [[Note]]` links
## Exam Traps Template
```markdown
---
keywords: exam traps, weak areas, common mistakes
---
# Exam Traps (시험 함정 포인트)
#dashboard #exam-traps
> [!warning] 이 노트의 목적
> 시험에서 자주 틀리거나 헷갈리는 포인트만 모은 **오답/함정 노트**입니다.
## <Topic 1>
> [!danger]- Trap: <Short description>
> - <What the trap is>
> - <Why it's confusing>
> - <The correct answer/approach>
> - [[Related Concept Note]]
---
## Related
- [[MOC - <Subject>]] → Weak Areas 섹션
- [[빠른 참조]]
```
## Concept Note Template
```markdown
---
source_pdf: <filename.pdf — MUST match verified Phase 1 mapping>
part: <part number>
keywords: <3-5 English keywords>
---
# <Title> (<Importance: ★~★★★>)
#<tag-from-registry> #<tag-from-registry>
## Overview Table (한눈에 비교)
| Item | Key Point |
|------|-----------|
| A | ... |
## <Concept 1>
Concise explanation (3-5 lines max).
- Bullet points for key facts
- Use **bold** for critical terms
---
## Exam/Test Patterns (시험 빈출 패턴)
| Scenario/Keyword | Answer |
|-------------------|--------|
| "keyword X" | **Solution Y** |
## Related Notes
- [[Other Note 1]]
```
### Formatting Rules
- `[[wiki-links]]` for cross-references
- `> [!tip]`, `> [!important]`, `> [!warning]` callouts
- Comparison tables over prose; bold for key vocabulary
### Visualization Rule
Include ASCII diagrams when applicable:
- Processes/stages → timeline or sequence diagram
- Signal/data flow → flow DAG
- Strategy comparisons → quantitative table
- State-based behavior → state transition diagram
### Simplification-with-Exceptions Rule
General statements must check for edge cases — add `> [!warning]` or link to exception details.
## Practice Question Template
```markdown
---
source_pdf: <filename.pdf — MUST match verified Phase 1 mapping>
part: <part number>
keywords: practice, <topic keywords>
---
# <Topic> Practice (N questions)
#practice #<topic-tag>
## Related Concepts
- [[Concept Note 1]]
> [!hint]- 핵심 패턴 (클릭하여 보기)
> | Keyword | Answer |
> |---------|--------|
> | pattern 1 | **Solution** |
---
## Question 1 - <Short Label> [recall]
> Scenario summary in one line
> [!answer]- 정답 보기
> Answer text here with explanation.
---
## Question 2 - <Short Label> [application]
> Given this scenario, what would you do?
> [!answer]- 정답 보기
> Answer with applied reasoning.
---
## Question 3 - <Short Label> [analysis]
> Compare X and Y in this context. Which is better and why?
> [!answer]- 정답 보기
> Comparative analysis answer.
---
> [!summary]- 패턴 요약 (클릭하여 보기)
> | Keyword | Answer |
> |---------|--------|
> | ... | ... |
```
### Practice Question Rules
- Every topic folder MUST have a practice file (8+ questions)
- **Answer hiding**: ALL answers use `> [!answer]- 정답 보기` fold callout
- **Patterns**: `> [!hint]-` / `> [!summary]-` fold callouts (MANDATORY)
- **Question type diversity**: tag `[recall]`, `[application]`, `[analysis]` in heading
- ≥60% recall, ≥20% application, ≥2 analysis per file
- Scenario in one `>` blockquote line; answer 1-3 lines in fold
- `## Related Concepts` with `[[wiki-links]]` (MANDATORY)