## Workcamp Manager — mandatory work tracking The `workcamp` MCP server is connected. Its `get_policy` tool holds the authoritative rules; follow them. **Non-negotiable:** (1) **no work without a ticket** — open or continue one *before* writing code, no "it's only small" exemption; (2) **always log time** on the ticket, as you finish chunks and always before closing — unlogged effort is invisible effort; (3) **document what you learned on a wiki page** (research, root causes, decisions, gotchas), not only in comments — **and tag that page on the ticket that prompted it** — and `search_wikis` before investigating. Summary: - **Resolve tracking, then open a ticket before coding.** 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/multi-repo root the pin is a local file). - `tracking: off` → untracked location (planning/scratch/personal): work normally, **no ticket, no time**, don't ask. - has `projectId` → use it. - nothing pinned → call `resolve_project` (folder name / short description) — it searches the whole camp, membership or not — and **ask the user**, offering: (a) an accessible match → confirm → pin `projectId`; (b) an existing project the user is NOT in → with their OK, `request_project_access(projectId)` (owner approves in the app; `find_project_owner` says who) → pin it but wait for approval; (c) a new project → only with explicit consent → `create_project`; (d) **don't track** → pin `tracking: off` (in `.workcamp.local.yml` if the repo is shared). Never auto-create or duplicate an existing project. When tracked, call `start_task` (opens ticket, sets **In Progress**, assigns the user). - **While working:** `log_progress(taskId, projectId, note)` for steps/decisions/blockers (always pass the pinned `projectId`). - **Track meaningful time:** log the hands-on hours actually spent advancing THIS ticket — not wall-clock/session time, not time on other tasks/tabs in between. Resuming after days? don't log the gap — add a fresh `log_time(taskId, projectId, hours, date?, note)` for that day's real effort (date defaults to today). Many entries per person/date; never overwrite. 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, reuse an open one you should continue (`search_tasks`: status "In Progress", assignee self); use subtasks/notes for the small pieces. - **Close on definition of done (you may do it yourself).** Once the ticket's full scope / acceptance criteria are met and verified, `log_time` then `complete_task(taskId, projectId, summary, scopeComplete: true)` and move on — no per-close approval needed. But don't close eagerly after one small change when the user is mid-conversation and likely to add more to the same ticket: keep it In Progress and keep working. Unsure the scope is done? ask. - **Pick & raise work:** use `find_next_task` to choose what to do next — you may pick up **unassigned** backlog tickets, not only ones assigned to you (claim via `start_task`; don't take someone else's without asking). Use `raise_task` to file unassigned backlog tickets for anyone to pick up, and `attach_evidence` to attach screenshots/files as proof when it helps. - **Lasting knowledge goes in a wiki, not a comment — and the ticket points at it:** research, investigations and their findings, decisions and their reasons belong on a project wiki page that outlives the ticket. `search_wikis` BEFORE investigating (it may already be written down) and before writing; then `create_wiki`, or `update_wiki` with `mode: "append"` to add findings without overwriting. **Always pass `taskId` + a one-line `brief`** so the ticket gets a hint of what the page covers plus a clickable tag of it — an unlinked write-up is one nobody knows to look for. Ticket = what's happening to this work; wiki = what is now known. - **Tag entities with `refs` (`#`):** tickets, milestones, wikis, teams and channels can be tagged inside any comment or note — `refs: ["wiki:", "ticket:"]` on `add_comment` / `log_progress` / `complete_task`. They render as live chips with the item's current title and status, and are clickable; a plain-text `#Something` is not a tag and links to nothing. `search_refs` turns a name or ticket number into the id. - **Every project needs a brief:** a project is created with a default "Project Description" wiki full of placeholder text. Pass `brief` to `create_project`, and call `ensure_project_brief` the first time you work in an existing project — if it reports `needs_brief`, write one (what the project is, what it delivers, who it's for, stack/repos/environments) and call again with it. A brief a human wrote is never overwritten. Never skip these or bypass a refused tool — surface the reason to the user. All actions are attributed to the connected Workcamp user.