refactor: carry the acceptance ID of a test in a tag, and drop docs/harness.md

The acceptance ID moves from the test title to a tag (Vitest `tags`,
Playwright `tag`), and the checker reads it only from the tags. The
docs/harness.md file and every reference to it are removed, and the
browser tests' access to storage is described as it is.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017UJLJcNU6V3ceKgzE23AZ1

Author: argentinaluiz

.claude/agents/revisor-conformidade.md

@@ -4,7 +4,7 @@ description: Confere, em contexto novo, se uma mudança entrega o que foi planej
 tools: Read, Grep, Glob, mcp__linear-server__get_issue
 ---
 
-Você confere a conformidade de uma mudança que outro agente escreveu com o que foi planejado para o ticket. Você não viu a implementação nem as justificativas de quem a fez: quem faz não avalia. Os defeitos gerais de código ficam com a `/code-review` e com o Copilot; o seu foco é o plano. O desenho está em `docs/harness.md`, seção "Revisor de conformidade".
+Você confere a conformidade de uma mudança que outro agente escreveu com o que foi planejado para o ticket. Você não viu a implementação nem as justificativas de quem a fez: quem faz não avalia. Os defeitos gerais de código ficam com a `/code-review` e com o Copilot; o seu foco é o plano.
 
 **O que conferir é o do `REVIEW.md` da raiz.** Leia-o primeiro e aplique-o inteiro: onde está o padrão, as conferências, a severidade e como ler. Aqui fica só o que depende do contexto local.
 

.claude/hooks/freeze-acceptance.sh

@@ -4,7 +4,7 @@
 # O arquivo de aceite de um ticket fica congelado depois do commit de plano: quando o agente vai
 # editar um docs/tickets/<issue>/<ticket>/aceite.md que já está em commit, nega a edição. Criar um arquivo
 # de aceite novo e editar qualquer outro arquivo, inclusive os outros da pasta do ticket, continuam
-# liberados. O desenho está no docs/harness.md.
+# liberados.
 #
 # Sai com 0 para deixar a edição rodar e com 2 para negá-la. No 2, o que foi escrito na saída de
 # erro volta para o agente.

.claude/hooks/push-verify.sh

@@ -7,8 +7,7 @@
 # na pasta de estado do harness (`.harness/`), onde ficam a trava e a aprovação; e o `git push`
 # que o `scripts/verify.sh prepush` não aprova, porque os commits trazem segredo ou o modo completo
 # não aprovou o último commit. As guardas são para um agente que coopera, e não uma barreira de
-# segurança. O desenho está no docs/harness.md, seções "Bloqueio no push" e "Trava das reprovações
-# repetidas".
+# segurança.
 #
 # Sai com 0 para deixar o comando rodar e com 2 para negá-lo. No 2, o que foi escrito na saída de
 # erro volta para o agente.

.claude/hooks/record-touched.sh

@@ -4,8 +4,7 @@
 # arquivos de apps/ que o agente editou, para o hook de fim de turno (stop-verify.sh) bloquear só
 # pelos erros desses arquivos. Um subagente traz o mesmo `session_id` da sessão que o chamou, então
 # as edições dele caem no arquivo dela. Edição por shell (sed, mv, gerador) não passa por aqui: é
-# um limite aceito, e o modo completo confere a árvore inteira. O desenho está no docs/harness.md,
-# seção "Hook de fim de turno".
+# um limite aceito, e o modo completo confere a árvore inteira.
 #
 # O `session_id` entra no nome do arquivo de estado, então só vale com letras, dígitos, `_` e `-`.
 # Com outro formato, ou sem `jq`, o hook não anota nada, e o hook de fim de turno avisa que não

.claude/hooks/stop-verify.sh

@@ -4,8 +4,8 @@
 # o modo rápido do scripts/verify.sh nas apps em que a sessão dele editou arquivos. Quem anota esses
 # arquivos, por sessão, é o record-touched.sh. Cada sessão só responde pelos arquivos dela: o erro
 # que outra sessão deixou no mesmo clone não bloqueia este turno, só avisa. Se falhar num arquivo da
-# sessão, devolve a saída ao agente, que continua o trabalho. O desenho, inclusive o limite da edição
-# por shell, que não é anotada, está no docs/harness.md, seção "Hook de fim de turno".
+# sessão, devolve a saída ao agente, que continua o trabalho. A edição por shell não é anotada,
+# então ela não entra nessa conta.
 #
 # Sai com 0 para deixar o turno encerrar e com 2 para bloquear. No 2, o que foi escrito na
 # saída de erro volta para o agente.

.claude/skills/implement-spec/SKILL.md

@@ -17,7 +17,7 @@ Communication to and from subagents should be sparse. Communicate primarily thro
 
 ## Steps
 
-1. Read the spec and tickets to understand the task graph. For each ticket, start from its plan commit and its acceptance file (`docs/tickets/<issue>/<ticket>/aceite.md`), as the root `AGENTS.md`, section "Plano do ticket", describes. If a ticket has no plan commit, stop and ask for `/plan-ticket` first. Every acceptance test carries its criterion ID in the title.
+1. Read the spec and tickets to understand the task graph. For each ticket, start from its plan commit and its acceptance file (`docs/tickets/<issue>/<ticket>/aceite.md`), as the root `AGENTS.md`, section "Plano do ticket", describes. If a ticket has no plan commit, stop and ask for `/plan-ticket` first. Every acceptance test carries its criterion ID in a tag.
 
 2. (optional) Use an **exploration subagent** to conduct any exploration required by the tickets - relevant codebase files or external documentation. Ensure the exploration subagent can save files - it should save its markdown notes in a directory outside the repo, accessible by all future subagents. This lets **implementer subagents** focus on implementation rather than exploration.
 

.claude/skills/implement/SKILL.md

@@ -8,7 +8,7 @@ Implement the work described by the user in the spec or tickets.
 
 If the user passes a ticket reference, fetch it from the issue tracker and state its title before starting. If the reference is ambiguous, ask.
 
-If the ticket has a plan commit, start from it and from its acceptance file (`docs/tickets/<issue>/<ticket>/aceite.md`), and put each criterion ID in the title of its acceptance test, as the root `AGENTS.md`, section "Plano do ticket", describes. If it has none, stop and ask for `/plan-ticket` first.
+If the ticket has a plan commit, start from it and from its acceptance file (`docs/tickets/<issue>/<ticket>/aceite.md`), and put each criterion ID in a tag of its acceptance test, as the root `AGENTS.md`, section "Plano do ticket", describes. If it has none, stop and ask for `/plan-ticket` first.
 
 Call the Skill tool with "tdd" where possible, at pre-agreed seams.
 

.claude/skills/plan-ticket/formatos/aceite.md

@@ -26,7 +26,7 @@ Ticket de exemplo. O CA1 é provado por teste HTTP, e o CA2, pela leitura do dif
 
 **Cenário:** Dado um Usuário com um item, quando ele o copia, então a cópia é criada com o nome dado.
 
-**Teste previsto:** testes de ponta a ponta da API, `items.e2e-spec.ts`, "copia o item @PROJ-123-CA1".
+**Teste previsto:** testes de ponta a ponta da API, `items.e2e-spec.ts`, "copia o item".
 
 ## PROJ-123-CA2
 
@@ -41,4 +41,17 @@ O arquivo de aceite não muda depois do commit de plano. Descongelar é do usuá
 
 ## Teste de aceite
 
-Cada teste de aceite leva no título o token `@<ticket>-CA<n>`, com o `@`, como `@PROJ-123-CA3`. O nome e o arquivo do teste podem mudar durante a implementação, porque a ligação com o critério é o ID.
+Cada teste de aceite leva o ID do critério numa tag, `@<ticket>-CA<n>`, com o `@`, como `@PROJ-123-CA3`, e não no título. O nome e o arquivo do teste podem mudar durante a implementação, porque a ligação com o critério é o ID. Um teste que prova mais de um critério leva uma tag por critério. O token no título não vale como ID.
+
+No Vitest, a tag vai nas opções do teste:
+
+```ts
+it('copia o item', { tags: ['@PROJ-123-CA1'] }, async () => {});
+```
+
+No Playwright, vai na opção `tag`, e várias tags formam uma lista:
+
+```ts
+test('o Usuário copia o item', { tag: '@PROJ-123-CA1' }, async ({ page }) => {});
+test('o Usuário copia e move o item', { tag: ['@PROJ-123-CA1', '@PROJ-123-CA2'] }, async ({ page }) => {});
+```

.github/workflows/ci.yml

@@ -1,7 +1,7 @@
 name: CI
 
 # O veredito do projeto: reexecuta a definição de pronto inteira, no mesmo Compose do
-# desenvolvimento. O desenho está no docs/harness.md.
+# desenvolvimento.
 
 on:
   pull_request:

.github/workflows/harness-guard.yml

@@ -1,7 +1,7 @@
 name: Guarda do harness
 
 # Reprova o pull request que altera um arquivo protegido do harness. Sem isto, um pull request
-# poderia enfraquecer a CI e ser aprovado pela CI enfraquecida. O desenho está no docs/harness.md.
+# poderia enfraquecer a CI e ser aprovado pela CI enfraquecida.
 #
 # O `pull_request_target` roda a versão da `main` deste workflow e do script, e não a do pull
 # request. O código do pull request nunca é baixado nem executado aqui.