## Workcamp Manager — mandatory work tracking This repo is governed by Workcamp. The `workcamp` MCP server is connected and its `get_policy` tool holds the authoritative rules — follow them. **Three things are non-negotiable:** - **No work without a ticket.** Open or continue one *before* you write code — not after, and "it's only a small change" is not an exemption. Untracked work can't be seen, scheduled or accounted for, and can't be reconstructed later. - **Always log time.** Every ticket gets `log_time` for the hours actually spent, as you finish chunks and always before closing. Unlogged effort is invisible effort — an honest estimate beats no entry. - **Write down what you learned — and link it back.** Research, investigations, root causes, decisions and gotchas go on a **wiki page**, not only in ticket comments — and the ticket that prompted the page must **point at it** (a one-line brief plus a real `#` tag). And `search_wikis` *before* investigating — it may already be written down. In short: 1. **Before writing code for any task, resolve tracking for this location, then open a ticket.** - Read the nearest pin file — `.workcamp.local.yml` (personal, gitignored) then `.workcamp.yml` (shared) — searching upward but **stopping at the repo boundary** (a sub-repo uses only its own pin). Git isn't required; at a non-git or multi-repo root the pin is just a local file. - If it sets **`tracking: off`** → this location is untracked (planning / scratch / personal). Work normally, **open no ticket, log no time**, don't ask. - If it has a `projectId` → use it. - If nothing is pinned, call `resolve_project` — it searches **every project in the camp**, including ones I'm not a member of — and **ask me**, offering four choices: (a) it's one of the accessible matches (confirm → pin `projectId`); (b) it matches an **existing project I'm not in** → with my OK, `request_project_access(projectId)` files a join request an owner approves in the app (`find_project_owner` says who) — pin it but wait for approval; (c) a new project to create (only with my explicit yes, via `create_project`); or (d) **don't track it** (pin `tracking: off` — in `.workcamp.local.yml` if the repo is shared). Never auto-create, and never create a duplicate of an existing project. - When tracked, call `start_task` (opens the ticket, sets **In Progress**, assigns me). 2. **While working**, call `log_progress(taskId, projectId, note)` for meaningful steps, decisions, and blockers (always pass the pinned `projectId`). 3. **Track meaningful time.** Log the hands-on hours actually spent advancing **this** ticket — not wall-clock/session time, and not time spent on other tasks or tabs in between. If I set it aside and come back days later, don't log the gap: add a fresh `log_time(taskId, projectId, hours, date?, note)` for that working day's real effort (decimal; date defaults to today). Many entries per person/date are fine; never overwrite. Always log before proposing to close. **Keep tickets coarse.** One ticket = one meaningful chunk over a few days (a feature, or a batch of fixes through to going live) — not one per micro-edit. Before opening a new ticket, check for an open one to continue (`search_tasks` status "In Progress", assignee me) and reuse it; use subtasks/notes for the small pieces inside a chunk. 4. **Close on definition of done — you may do it yourself.** When a ticket's full stated scope / acceptance criteria are met and verified (built and working / tests pass), log a closing summary, `log_time`, then `complete_task(taskId, projectId, summary, scopeComplete: true)` and move to the next ticket — no need to ask me each time. But **don't close eagerly**: if you've only done a small part, or I'm mid-conversation and likely to add more to the **same** ticket, keep it In Progress and keep working. If you're genuinely unsure the scope is complete, ask; otherwise use your judgement. 5. **Pick up work — including unassigned tickets.** Use `find_next_task` to see what to work on next: it ranks tickets assigned to me **plus the unassigned shared-backlog pool anyone can pick**, by priority and due date. You may claim an unassigned ticket (`start_task`, assign it to me); don't take one already assigned to someone else without asking. To capture work for later, use `raise_task` to file an **unassigned backlog** ticket for anyone to pick up. 6. **Attach evidence.** When a screenshot or file would prove or explain the work (a passing/failing screen, a log, an artifact), use `attach_evidence` — read the local file, pass its bytes as base64. Prefer this over pasting large blobs. 7. **Put lasting knowledge in a wiki, not a comment — and tag it on the ticket.** Research, investigations and their findings, decisions and the reasons behind them belong on a project wiki page that outlives the ticket — ticket comments are scoped to one ticket and nobody re-reads a closed one. **`search_wikis` before you investigate** (the answer may already be written down) and before you write, then `create_wiki`, or `update_wiki` with `mode: "append"` to add a new round of findings without overwriting what's there. **Always pass `taskId` + a one-line `brief`** so the ticket carries a hint of what the page covers and a clickable tag of it — a write-up nobody can find from the work that prompted it may as well not exist. Keep the ticket for what's happening to *this work*; keep the wiki for what's now *known*. 8. **Tag things properly (`#`).** Tickets, milestones, wikis, teams and channels can be tagged inside any comment or note — the `#` picker in the app, the `refs` parameter over MCP (`refs: ["wiki:"]` on `add_comment` / `log_progress` / `complete_task`). They render as live chips showing the item's current title and status, and are clickable. Typing `#Something` as plain text is **not** a tag: it looks like one and links to nothing. Use `search_refs` to turn a name or ticket number into the id. 9. **Every project needs a brief.** A project is created with a default "Project Description" wiki full of **placeholder text** — the first page anyone opens, explaining nothing. Pass `brief` whenever you create a project, and the first time you work in an existing one call `ensure_project_brief`: if it reports `needs_brief`, write a real one (what the project is, what it delivers, who it's for, stack/repos/environments) and call again with it. A brief a human has written is never overwritten. Do not skip these steps or work around a refused tool — relay the reason to me. Everything you do is logged under my Workcamp identity.