work_tracking section (hoen.yaml)¶
Deterministic repo ↔ board linkage under work_tracking in
hoen.yaml. Git remains source of truth for plan text and
effort JSON; this section tells agents which board, which repo, and
where plans live. Optional field IDs after bootstrap live here too — not
per-plan card rows.
Schema (version 1)¶
| Field | Required | Purpose |
|---|---|---|
backend |
yes | notion | github_projects (Jira planned) |
component_type |
yes | Board filter — one per git repo |
board.* |
yes | Backend-specific board identity (below) |
repository.host |
yes | e.g. github.com |
repository.org |
yes | GitHub org or user |
repository.name |
yes | Repo name |
repository.default_branch |
yes | For Plan doc blob URLs |
repository.plan_globs |
optional | Hints for discovering plan/ADR markdown |
Board keys by backend¶
notion — board.name, board.url, board.data_source_id (required);
board.fields.* optional after bootstrap.
github_projects — board.name, board.url, board.owner,
board.project_number (required); board.owner_type (org default),
board.project_id, board.fields.* optional.
Do not add per-plan rows to hoen.yaml.
Plan doc linkage¶
One slim section for every backend — see skill SKILL.md and repo-conventions-template.md:
## Tracking
| Field | Value |
|-------|-------|
| **Plan ID** | `my-plan-slug` |
| **Work type** | Epic |
| **Board item** | <url or issue key> |
If hoen.yaml is not committed, Plan ID + Board item still allow sync for that item.
Resolution order¶
- Plan
## Tracking/ frontmatter (plan_id, board item /tracking_issue) hoen.yaml→ board + repository- Backend orchestrator or adapter (
sync-from-hoen.mjsfor GitHub) - Create board item only when bootstrapping