External/roboco
1
0
Fork 0
mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs(release): prepare 0.27.0 — curated changelog, rag/map sweep, concat rebuild script (#662)

Browse Source
This commit is contained in:
Renzo F
2026-07-23 11:33:02 +02:00
committed by GitHub
parent d8841279a8
commit dd4c3c3ed0
26 changed files with 501 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/rag/workflows/task-claiming.md
+3 -1
View File
@@ -27,7 +27,9 @@ claim_doc_task(task_id) # Documenter
The claim verb both claims and starts the task — there is no separate `start` call. For developers, `i_will_work_on` also creates the `feature/{team}/{task-hierarchy}` branch and **adds a dedicated per-task worktree** at `{clone_root}/.worktrees/{task-id-first-8}/`, checking out the branch there. Your container is started with that worktree as its cwd, and the clone root's HEAD is never moved by the claim — so a second claim (or a coordinator PM's many parallel roots) never overwrites your first task's uncommitted work. See `docs/rag/architecture/workspaces.md` for the worktree model.
Exactly one active WorkSession exists per task at a time (enforced in the service layer and by a DB unique index). A re-claim — pool release, reaper unclaim, escalation redirect — supersedes any prior agent's stale active session for that task and re-points the worktree at the new claim.
Exactly one active WorkSession exists per task at a time (enforced in the service layer and by a DB unique index). A re-claim — pool release, reaper unclaim, escalation redirect, or your own `i_will_work_on`/`i_will_plan` re-entry — supersedes any prior agent's stale active session for that task and re-points the worktree at the new claim.
If the branch you're reclaiming was cut a while ago, the base it branched from may have advanced since (a sibling merged into the parent, or a cell PR landed on root). The claim automatically folds that advance into your existing branch: an already-ancestor base is a no-op, a clean merge just happens silently, and a real conflict leaves your branch exactly where it was and appends a note plus a `dev_notes` line telling you to run `sync_branch(task_id)` to finish it by hand — the claim itself never fails over this. This only runs on developer/cell_pm/main_pm claims of a `pending`/`needs_revision` task; a QA/documenter claim or a PM gate claim reviews the branch exactly as pushed and never touches it.
If your task has `dependency_ids` in the same repo, the fresh branch cut also backfills each dependency's already-landed work when it sits outside your branch's own ancestor chain (a same-parent sibling or a same-project wave usually doesn't need this — the shared base already has it; a cross-subtree or cross-cell dependency edge can). This is a content assist, not a gate: a clean merge is silent, and a real conflict aborts the merge (your branch is left exactly at its cut point) and appends a note to the task naming the conflicting branch and files — resolve it by hand (merge the named branch into yours) before assembling your PR. A cross-repo dependency has no shared git history and is skipped entirely.