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.
Default é respeitar o lock. Carve-out é a exceção codificada com trilha de auditoria — não permission slip pra contornar.
R1 — Default: respect-the-lock
Se <component> tem lock exclusivity: hard ativo de outra sessão em meta/context/notices/active/lock-<slug>.md, não inicie nova sessão de implementação no componente até o lock ser arquivado.
Esta é a regra base. R2–R5 abaixo são derrogações estritas.
KVS#202 Stage 1 (owner-approved 2026-06-04): desde o flip de
kvs wcpra caminho default de commit, o lock por-componente é advisory por default — R1 e o carve-out R2–R5 só se aplicam a locksexclusivity: hard(migração/ rebrand/release; e, na transição, locks sem o campoexclusivity). Para um lock advisory, não há carve-out a fazer: edição concorrente normal no componente é segura viakvs wc commit(no-index, path-scoped) — siga direto, sem courtesy notice nem restrição R2. Vertasks/concurrent-lock.md§3.
R2 — Operações collision-free (carve-out permitido)
Carve-out é permitido somente 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 package 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 |
backlogpending* seria erro de categoria (no-op
em ~941 tickets comuns sob um gate strict). É garantida **no write-time** pela
**R3 step 2** (o carve-out estampa lock_carveout: ao inserir) e auditável
retroativamente pela passada dedicada koder-spec-audit lock-carve-out --impact
(a ser implementada — cruza histórico de locks × inserts), fora do run` genérico.
Relação com tasks/concurrent-lock.md
tasks/concurrent-lock.md é o protocolo operacional (check/ place/archive). Esta policy é o mandate semântico sobre quando exceções existem. Comandos como /k-go, /k-commit, /k-housekeep chamam o task pra placar lock; quando o task reporta conflict, esta policy decide se há carve-out aplicável OU se o trabalho para.
Precedente
Caso seminal: 2026-05-23 — hub-session abriu 2 tickets em products/horizontal/kruze/app/backlog/pending/ (kruze#174 + #175 da wave Kruze headless) durante lock ativo da wave 11 (KRUZE-162.2-c). Owner perguntou se havia mecanismo de alerta cross- session, foi explicado o notices/active/ channel, autorizou explicitamente, carve-out executado conforme R3. Wave 11 viu o notice no system-reminder do próximo turn dela, terminou seu trabalho, arquivou seu lock — notice também arquivada na mesma janela. Zero collision, zero drama. Commit 8897ce7d7b.