Lock carve-out — collision-free ops allowed under sibling-session lock
Quando outra sessão tem lock ativo em `<component>` (per `tasks/concurrent-lock.md`) mas a operação pedida pelo owner tem zero risco de collision com o trabalho da sessão dona do lock, carve-out é permitido sob procedimento estrito: courtesy notice em `meta/context/notices/active/` + frontmatter pointer no artefato + `git commit -o <pathspec>` pra não contaminar o index. Operações collision-free são pre-cataloged em §R2; tudo fora dessa lista exige o lock arquivado antes.
Policy — Lock carve-out
Default é respeitar o lock. Carve-out é a exceção codificada com trilha de auditoria — não permission slip pra contornar.
R1 — Default: respectthelock
Se <component> tem lock ativo de outra sessão em meta/context/notices/active/lock-<slug>.md, *ão inicie*nova sessão de implementação no componente até o lock ser arquivado.
Esta é a regra base. R2–R5 abaixo são *errogações estritas*
R2 — Operações collisionfree (carveout permitido)
Carve-out é permitido *omente*para operações desta lista fechada — toda outra ação fica sob R1:
| Operação | Por quê collision-free | Procedimento |
|---|---|---|
Inserir ticket novo em <component>/backlog/pending/ ou /done/ |
Arquivo novo, nome único (próximo ID livre). Lock-holder não toca backlog files. | R3 |
Adicionar entry em CHANGELOG histórico (## v0.X.Y — date) acima de "Unreleased" |
Release já cortada; lock-holder edita "Unreleased" abaixo, não a entry histórica. | R3 |
Bootstrap de *ackage NOVO*em domínio relacionado (ex.: engines/sdk/<new_pkg>/) |
Novo diretório, nenhum arquivo do lock-holder. | R3 |
| READMENOTICE factual em `component` (ex.: corrigir typo, adicionar status badge histórico) | Edit atomic line; conflito de merge se houver é trivial. | R3 + cuidado extra |
| Doc carve-out: criar/editar `policies |