# English workflow

The project documentation is 100% English on purpose: the repo is an immersion environment.
Rust is learned through English, English through Rust.

## Daily habits (zero extra time)

- **Commit messages in English** — Conventional Commits format forces short, structured sentences.
- **DevLog entry** (10 min, last step of every session): 3–5 sentences about what you did,
  in English. Don't translate from Russian in your head — describe the code, not the feelings.
  Obsidian **Daily notes** is wired to this habit: folder `docs/devlog`, filename `YYYY-MM-DD`,
  template `TMP/DevLog.md` — open today's note via the ribbon calendar icon or the command
  palette ("Daily notes: Open today's daily note"). The config lives in `.obsidian/`
  (gitignored), so re-create it manually on a new machine.
- Each DevLog auto-renders a **"Files touched today" table** (Dataview community plugin, v0.5.70,
  installed in `.obsidian/plugins/dataview/`). The query filters by `file.mtime` inside the day
  taken from the note's own filename, so every past entry shows its own day, not "today".
  Caveat: `mtime` shows the *last* touch — a note edited again later moves to the newer day's
  table. For the true change history of code files (`.rs` is not indexed by Dataview) use git:
  `git log --since="00:00" --name-only --pretty=format:`.
- **Read error messages and docs in English only.** Never switch the compiler or Rust Book to Russian.

## Weekly habits

- **One article per sprint** in `articles/` (comparison, tutorial, retro) — reviewed for
  language quality, not only content. Keep sentences short; prefer active voice.
- **Glossary growth**: every new term goes to `learning/glossary.md` with your own example
  sentence. Re-using a term in your own sentence is what makes it stick.
- Weekly self-check: read Monday's DevLog aloud — if you can't, the sentence was too complex.

## What gets reviewed

| Artifact | Language focus |
|----------|----------------|
| Commit messages | imperative mood, conciseness |
| DevLog | past simple, describing actions |
| Issues / task notes | acceptance criteria phrasing ("must exist when done") |
| Articles | structure, connectors, technical vocabulary |
| Code comments & rustdoc | explaining "why", not "what" |

## Rules of thumb

1. Simple sentences first; compound later. Clarity beats sophistication.
2. If you needed a dictionary twice for one sentence — rewrite the sentence, not the vocab.
3. Write first, polish after; never let language anxiety stop the log entry.
4. Track words you *meet* vs words you *use* — the second list is the real progress.