sinkra-os: bundle entrega 4 regras de permissão mortas Write(path) — aviso em toda abertura de sessão, e o deny de .claude/** nunca valeu

[lk1407]

Sintoma

Toda abertura de sessão Claude Code num projeto do Cohort imprime 4 linhas de aviso antes de
qualquer interação — em macOS e Windows. O texto diz que as regras Write(path) do
.claude/settings.json não são avaliadas: apenas Edit(path) casa com as ferramentas de escrita.
É a primeira coisa que o aluno vê ao abrir um pane.

Permission allow rule (.claude/settings.json): Write(workspace/output/**) is not matched by file
permission checks — only Edit(path) rules are. Use Edit(workspace/output/**) instead (Edit rules
cover all file-editing tools).

(idem para Write(.sinkra/state/**), Write(.sinkra/extraction/**) e, em deny, Write(.claude/**))

Ambiente

• OS: macOS 13.7.8 (x86_64) + Windows (mesmo aviso, reportado por aluno) · Cockpit: v0.11.1.0 ·
  Claude Code: 2.1.235 · Antivírus: nenhum além do nativo
• Bundle: .claude/settings.json, merge_strategies: deep-merge-json, presente no MANIFEST como
  bundle/.claude/settings.json (self_contained: true)
• sinkra-os (loader npm): 3.8.0

O que o diagnóstico encontrou

1. As 3 regras de allow são duplicatas mortas. O bundle já entrega o par Edit(...)
equivalente logo acima de cada Write(...). Remover as Write não muda comportamento nenhum —
só cala o aviso. [ALTA]

2. A regra de deny nunca valeu. Write(.claude/**) está em permissions.deny — ou seja, o
bundle acredita proteger .claude/, e não protege. Nunca protegeu, na versão atual do Claude
Code. O aviso estava anunciando isso e passou despercebido. [ALTA]

3. Converter Write(.claude/**) → Edit(.claude/**) é a correção ERRADA. Se essa proibição
passar a valer de verdade, quebra dois caminhos do próprio framework:

• /sinkra-create-skill (Forja) — o stage-runner sinkra-creator-gerar tem como boundary
  declarado "escreve SÓ .claude/skills/ + .sinkra/forge/". Com o deny ativo, a Forja não
  materializa skill nenhuma.

• /cohort-bootstrap — reescreve .claude/ inteiro por definição.

  A correção segura é remover a linha (ela já é inerte hoje, então remover é no-op de
  comportamento), ou substituí-la por um deny estreito que não cubra .claude/skills/**. [ALTA]

4. O aluno não consegue consertar isso sozinho de forma durável. Em
sinkra-os@3.8.0/lib/merge-engine.js, deepMergeJson resolve kind por
rp.endsWith('settings.json') → 'settings' (linha 260), e nesse ramo faz:

const MANAGED = ['permissions', 'hooks', '_sinkra_managed'];
result = { ...student };
for (const k of MANAGED) if (k in bundleJson) result[k] = bundleJson[k];

permissions é bundle-wins, sobrescrita integral — não é união. Logo, qualquer correção que o
aluno (ou nós) faça no .claude/settings.json do projeto é apagada no próximo
sinkra-os install/update, e o aviso volta. O único conserto durável é no bundle. [ALTA]

5. Segunda fonte do mesmo defeito, e desatualizada. O template usado pelo /cohort-bootstrap
(.claude/skills/cohort-bootstrap/templates/.claude/settings.json) tem as mesmas 3 regras mortas
e além disso está em regime antigo: SINKRA_VERSION: "v4" e libera .aiox/** em vez de
.sinkra/**. Ou seja, re-scaffoldar hoje entrega permissões que não correspondem às pastas que o
V5 realmente usa. [ALTA]

Passos para reproduzir

1. Instalar/atualizar um projeto do Cohort pelo bundle (sinkra-os install).
2. Abrir qualquer sessão Claude Code (2.1.x) na raiz do projeto — pane do Cockpit ou terminal.
3. As 4 linhas de aviso aparecem antes do primeiro turno. Em toda janela nova, sempre.
4. Editar o .claude/settings.json para remover as regras Write(...) → aviso some.
5. Rodar sinkra-os install de novo → permissions é sobrescrita pelo bundle → aviso volta.

Correção sugerida (no bundle)

bundle/.claude/settings.json:

• remover as 3 linhas Write(...) de allow (os pares Edit(...) já existem)
• remover a linha Write(.claude/**) de deny — não convertê-la para Edit(...) (ver item 3)
• separar Bash(node:*,npm:*) em Bash(node:*) + Bash(npm:*) — vírgula dentro de uma regra só
  não é a sintaxe documentada [MÉDIA — não emite aviso, mas é suspeito de não casar]

E aplicar a mesma correção ao template do cohort-bootstrap, junto com o refresh v4→v5
(.aiox/** → .sinkra/**).

Classificação [Confiança: ALTA]

bug — do bundle sinkra-os, não do Cockpit. Duas consequências independentes: ruído em 100%
das aberturas de sessão de 100% dos alunos (o primeiro contato com o produto), e uma regra de
governança que o framework acredita ter e não tem. Não é auto-corrigível pelo aluno por causa do
bundle-wins em permissions.

Labels sugeridas: bug, os:both, severity:minor
(não tenho permissão de triage no repo para aplicá-las na criação)

[lk1407]

Achados adicionais ao investigar o conserto do lado do projeto. Dois deles mudam o escopo da
correção — vale ler antes de mexer no bundle.

1. Existe uma TERCEIRA via que apaga a correção do aluno, além do bundle-wins do item 4.

O scaffolder /cohort-bootstrap (scripts/bootstrap.js) copia templates/ com writeFileChecked,
que sobrescreve incondicionalmente qualquer arquivo cujo conteúdo difira do template:

const existing = readFileBytes(destPath);
if (existing && sha256(existing) === newHash) { log.push(`[no-change] ${relKey}`); return { changed: false }; }
const action = existing ? '[update]' : '[create]';
if (!dryRun) fs.writeFileSync(destPath, buf);

Ou seja, /cohort-bootstrap --target . num projeto existente substitui o .claude/settings.json
do aluno pelo do template. O CLAUDE.md distribuído promete "Idempotente — não apaga seu
workspace/output/", o que é verdade para o output, mas não vale para o settings.json. Somando:
sinkra-os install, sinkra-os update e /cohort-bootstrap — três caminhos, todos sobrescrevem.
A correção precisa entrar no bundle E no template do cohort-bootstrap, ou os dois divergem.

2. Edit(.aiox/**) NÃO é resquício — é permissão viva. Não remover.

Corrijo um ponto do item 5 do relato original: eu tinha classificado .aiox/** como regime antigo.
Está errado. O próprio /cohort-bootstrap grava <target>/.aiox/bootstrap-report.json (AC11,
SKILL.md:65,85,98), e o Cockpit mantém cockpit-integration.json, daemon.json e
telemetry/ no mesmo diretório. A correção certa é manter Edit(.aiox/**) e acrescentar
as do .sinkra/, não trocar.

3. O template não concede as pastas de estado do V5 — nenhuma delas.

templates/.claude/settings.json não tinha .sinkra/state/** nem .sinkra/extraction/** em
lugar nenhum (nem como Write, nem como Edit). Um projeto recém-scaffoldado pede confirmação
a cada escrita de progresso/checkpoint do pipeline V5 — que é exatamente o caminho quente do
/sinkra-pipeline. Isso é independente do bug das regras mortas e provavelmente passou
despercebido porque o settings.json do bundle (que tem as duas) mascara o defeito em projetos
instalados pelo bundle.

4. COHORT_VERSION desalinhado em 3 lugares.

package.json do repo = 5.0.0; settings.json do bundle = 5.0.0; mas
bootstrap.js:24 = '1.0.0', SKILL.md:103 (exemplo do report) = "1.0.0" e o template
= "1.0.0". O bootstrap-report.json de um projeto scaffoldado saía carimbado com a versão
errada.

Correção aplicada localmente, como referência do que o bundle deveria entregar:

{
  "permissions": {
    "allow": [
      "Read(**/*)",
      "Edit(workspace/output/**)",
      "Edit(.sinkra/state/**)",
      "Edit(.sinkra/extraction/**)",
      "Edit(.aiox/**)",
      "Bash(node:*)",
      "Bash(npm:*)"
    ],
    "deny": [
      "Read(.env*)"
    ]
  },
  "env": { "SINKRA_VERSION": "v5", "COHORT_VERSION": "5.0.0" }
}

(Edit(.aiox/**) sai da lista no settings.json do bundle se lá o .aiox/ não for usado —
no template do cohort-bootstrap ele é obrigatório.)

Ponta solta que não toquei: templates/package.json ainda declara version: "1.0.0" enquanto
o package.json do repo é 5.0.0. Não mexi por ser a versão do projeto do aluno, não a do
Cohort — mas provavelmente é a mesma deriva.

[aiox-cockpit-triage]

@lk1407, recebido — este relato entrou na fila de triagem do AIOX Cockpit.

Segundo o relato, toda abertura de sessão exibe quatro linhas de aviso dizendo que parte das regras de permissão do projeto não é avaliada. Além do ruído recorrente, a restrição que deveria proteger uma das pastas de configuração nunca chegou a valer na prática.

Gravidade registrada: major

Esse resumo e esse rótulo foram gerados automaticamente e podem ser revistos por uma pessoa da
equipe. Se algo acima não corresponde ao que você quis dizer, responda aqui — a correção entra na
fila junto. Nenhuma issue é fechada automaticamente.

Obrigado por registrar.

— comentário automático de recebimento