# SCOPE: activation in a NEW project with NO CODE (day 0 — during planning).
# Until the codebase exists, only knowledge/ (OKF) + instructions + wrapper make sense.
# The graph (prompt.txt) only pays off once there are sources to index — do NOT run
# graphify on an empty tree. For the per-machine style, use prompt-style.txt.
# Distinct artifacts — do not merge them.

This is a new project, still without code. I am in the planning stage. Inject NOW
whatever speeds things up and does not depend on a codebase — the graph waits until
there are sources. Execute the steps and do not invent code:

1. STYLE (per machine, once): if I have not installed it yet, paste/apply
   YGGDRASIL/prompt-style.txt (output style + global instructions). If it is
   already active, skip.

2. INSTALL THE KIT IN OKF-FIRST MODE (no graph required):
   `python3 YGGDRASIL/scripts/setup.py --okf`
   This creates the `knowledge/` scaffold (README + TEMPLATE + log), writes `AGENTS.md`
   with the OKF-mode navigation (single source; `CLAUDE.md` and `.cursor/rules/` get
   pointers only), installs the output wrapper and emits
   `graphify-out/KNOWLEDGE_REVIEW.md`. It does NOT generate a PROJECT_MAP or labels —
   there is no graph, and an empty map is worse than an absent one.
   (Without `--okf` the setup detects this on its own: zero code files = OKF mode. The
   flag forces the mode even when some stray code already exists.)
   Check the CONTENT LANGUAGE it reports — it decides the language of the knowledge
   files you are about to write. Fix it now if wrong: `--content-language <tag>`.

3. KNOWLEDGE/ (OKF) — the project's own memory from day 0. Answer the
   KNOWLEDGE_REVIEW.md and write the knowledge/<slug>.md files that can ALREADY be
   crystallized from planning. Start with the 2–3 most valuable ones (priority, not a
   limit). "Don't document for the sake of documenting" = do not duplicate what the
   code will tell; it does NOT mean document little:
     * `architecture-decision-<x>.md` (type: Architecture Decision) — the choice + the
       why + the date + context ("in YYYY-MM we chose Y because Z; worst case: W").
     * `<service>-contract.md` (type: API Contract) — endpoints/fields/auth/limits of
       external APIs this project will consume or expose.
     * `business-rule-<x>.md` (type: Business Rule) — rules that will become queries or
       logic and are NOT obvious from the future code.
     * `runbook-<x>.md` (type: Runbook) — sequences someone will need to run.
   Keep the `type:` values in these canonical English strings — they are matched by
   tooling. The prose follows the project's content language.
   Use `resource:` to point at the canonical URI when the rule lives outside git.
   Link concepts to each other with ./other.md (they become edges once indexed).
   Record every creation in knowledge/log.md.

4. AGENTS.md — write the project-description section from the planning (3–6 lines:
   planned services/modules, stack, where the contract/schema will live, non-obvious
   decisions). It is the context starting point when a session begins. Write it IN
   AGENTS.md, not in CLAUDE.md — the latter is only a pointer (`@AGENTS.md`), and
   duplicated text there becomes the second truth that ages.

5. DO NOT DO (yet): graphify / `/graphify` (an empty codebase means a useless graph
   and labels with no nodes), LABELS_REVIEW (there are no communities).

6. WHEN THE CODEBASE IS BORN (even a little: structure, config, .proto, skeleton
   handlers): run `graphify` (Claude Code: `/graphify`) + `python3
   YGGDRASIL/scripts/setup.py` — WITHOUT `--okf` this time. The kit is promoted to
   full mode: PROJECT_MAP, labels, and the accumulated knowledge/ indexed into the
   graph. Nothing you wrote now is lost: `knowledge/` and the project description
   survive the promotion.

At the end, show me: the list of knowledge/*.md created (with each one's type) and the
project-description section of AGENTS.md. Keep everything editable and dated.
