1. **One root question first** — Then branch from there

2. **Written criteria** — So branches stay consistent, not just feeling-based

3. **Leaf = action or decision** — Not "maybe" or "we'll see"

4. **Depth of 3–4 levels** — Deeper is hard to maintain

5. **Write the "why"** — One sentence per branch so context doesn't get lost

6. **Trees go stale** — Requirements change; treat them as living docs

7. **Check what already exists** — ADR or existing tree before creating a new one

8. **Simple > complete** — Something that gets used beats something perfect that nobody opens

- **Root** — The top-level question or condition (level 0)

- **Branch** — Each answer or criterion forms a branch

- **Leaf** — End of a branch: a decision or action you can actually take

Short example: "Need per-service scale within 12 months?" → Yes → consider microservices / modular monolith; No → start with a simple monolith. It doesn't have to be formal; what matters is that the flow is readable and reusable.

- One or two questions are enough; no need to map a full tree

Jump straight to: "REST or GraphQL? SQL or NoSQL? Monolith or microservices?" — everything floats, no logical order.

"Let's just use X." — Six months later nobody remembers why.

- "Use modular monolith; separate domains by folder, deploy as one unit"

- "Use GraphQL for public API; REST for internal"

- "Choose monolith because team is small and MVP in 3 months; refactor to microservices only if we see real bottleneck evidence."

- "GraphQL for public because mobile clients need query flexibility; REST for internal because it's simpler and tooling already exists."

- The process never exits naturally; it must be killed externally.

- **Resource efficiency**: Poor for non-real-time workloads; consumes resources 24/7.

- **Error handling**: Unhandled exceptions can crash the entire process; need robust recovery.

- **Memory leaks**: Dangerous in long-running processes; accumulate over time.

- **Monitoring**: Clear success/failure metrics per execution; easy to track.

- **Scalability**: Multiple instances can run safely; scheduler handles coordination.

- Keep depth reasonable; avoid path chains longer than needed

- Frontmatter + structured body; body starts with H1 = note title

**First line of body:** `# Note Title` (H1, same or close to `title` in frontmatter). Kyong always uses this; we follow.

- **## まとめ** (or **## Summary**): summary; end with **結論:** or one takeaway sentence (italic allowed).

Real flow example: [note Claude Code CLAUDE.md](https://github.com/kyong0612/learning-notes/blob/main/articles/Claude%20Code%20%E3%81%AE%20CLAUDE.md%E3%81%AF%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%9F%E6%96%B9%E3%81%8C%E3%81%84%E3%81%84/note.md) — はじめに → CLAUDE.mdとは → ワークフロー → TDD → ツール → … → まとめ + 結論.

One concept per file; fixed sections. Optional extra sections (e.g. a deeper dive) are allowed.

- **## Examples**: concrete examples; label **Good:** / **Bad:** (or **Better:** / **Good to know:** as needed).

| Aspect | Rule |

| --------------- | --------------------------------------------------------- |

| **Density** | Short sentences, one idea per sentence. Avoid filler. |

| **Punctuation** | Use periods, commas, colons. Avoid excessive em dash (—). |

| **Examples** | **Good:** / **Bad:** (text only, no emoji). |

| **Closing** | One italic sentence; direct and humble. |

- Hash tables and arrays (by index) are your main tools for O(1) access; use them when the problem allows.

- **O(1)**: runtime bounded by a constant; independent of input size.

- **Use it for**: index access, hash lookups, reading a fixed field; aim for it on hot paths when possible.

This note covers **O(2ⁿ) exponential time**: the complexity class where the number of operations grows exponentially with _n_, e.g. doubling each time _n_ increases by 1. Typical pattern: exploring **all subsets** of _n_ elements (each item: in or out → 2ⁿ outcomes). Unlike O(n!): 2ⁿ = all subsets; n! = all orderings. Exponential algorithms become impractical very quickly; even for moderate _n_ (e.g. 30–50), 2ⁿ is huge. **Goal:** avoid enumerating all subsets or binary combinations unless _n_ is very small; recognize the "two choices per step, n steps" pattern and consider pruning, memoization, or DP.

**O(2ⁿ)** means the running time is bounded by a constant times 2ⁿ (or more generally, cⁿ for some constant c > 1). So each time you add one to _n_, the worst-case work multiplies by a fixed factor (e.g. 2).

- 2^10 ≈ 1,000; 2^20 ≈ 1 million; 2^30 ≈ 1 billion. So "exponential" is not something you want for large _n_.

- Big O allows any exponential base (2ⁿ, 3ⁿ, etc.); we write 2ⁿ as the standard example for "exponential in n."

**A decision tree that doubles at each step.** At each of _n_ steps you have two choices (e.g. yes/no, include/exclude). So you have 2×2×…×2 = 2ⁿ possible paths. Exploring all of them means 2ⁿ leaves. The tree "fans out" very fast. That's exponential growth. No way to avoid the explosion unless you prune or don't enumerate everything.

- **Enumerating all subsets**: e.g. "try every subset of items" (2ⁿ subsets). Each element is either in or out, so 2 choices per element, so 2ⁿ.

- **Recursion with two (or more) branches per call**: e.g. Fibonacci done naively (each call branches into two), or recursive backtracking that tries two options at each step without memoization or pruning.

- **Some exact algorithms for NP-hard problems**: e.g. brute-force SAT (try all 2ⁿ truth assignments), or subset-sum by trying all subsets. Often the best _exact_ algorithm we have is exponential; we then rely on heuristics, approximation, or small _n_.

You do **not** get O(2ⁿ) from a single loop (O(n)) or from nested loops with a fixed depth (e.g. O(n²), O(n³)). The key is "number of steps or choices grows with n, and we're doing work proportional to the number of outcomes."

- **O(2ⁿ)**: work proportional to 2ⁿ (or cⁿ); typical pattern is exploring all subsets or all n-step binary choices.