hwipit/plugin

Execute isto exatamente como escrito — os argumentos vão na segunda linha do heredoc, nunca no próprio comando, em uma linha, e apenas as palavras quiet normal loud mute unmute --global approve on off:

bash "${CLAUDE_PLUGIN_ROOT}/scripts/hwip-mode.sh" <<'HWIP_MODE_INPUT'
${CLAUDE_PROJECT_DIR}
$ARGUMENTS
HWIP_MODE_INPUT

Saída 2 significa argumento inválido — mostre ao usuário a linha de uso que foi impressa. Caso contrário, relate as linhas de status com suas próprias palavras:

• NOTIFICATIONS: muted → os hooks Stop e Ask estão silenciados aqui; as ferramentas hwip_* ainda funcionam, mas não são chamadas a menos que o usuário peça. Mute anula qualquer nível.
• PUSH MODE: quiet → apenas pushes de alta prioridade (bloqueadores, high Push Signal) enquanto o usuário está no terminal, além de um push de conclusão após ele se afastar (HWIP_AWAY_SEC, padrão 300 s) ou sempre que o painel tmux desta sessão não estiver visível na tela. O padrão fornecido.
• PUSH MODE: normal → um push a cada etapa que realizou trabalho real, silencioso em etapas somente leitura; os marcadores Push Signal decidem os casos de borda.
• PUSH MODE: loud → toda etapa envia push, ignorando skip.
• O parêntese indica a origem do nível: this project, global default (definido com --global, herdado por projetos sem nível próprio), ou o padrão interno. Um nível de projeto sempre anula o global.
• APPROVAL GATE: on|off → se comandos Bash difíceis de desfazer (rm -rf, force push, deploy em produção, SQL destrutivo) aguardam aprovação neste projeto. No terminal, o próprio prompt de permissão do Claude Code pergunta; ausente, em REMOTE, ou quando a presença não pode ser lida, o telefone do usuário faz isso. on, but inactive while muted — um projeto mutado não tem a quem perguntar, então nada é retido.
• SCOPE: … → os níveis, mute, portão de aprovação e modo automático pertencem ao diretório do projeto, não à sessão: uma segunda sessão do Claude no mesmo diretório os compartilha. Diga isso quando o usuário alterar um deles.
• AUTO MODE: … → uma sessão /hwip-auto está em execução com esse orçamento restante. off (an expired … session left its state behind — cleared) indica que uma falhou.
• LAST PUSH: … → o registro do CLI de sua última push com falha (hwip notify escreve isso, uma push bem-sucedida o apaga). Os hooks ocultam os erros do notify, então esta linha é como "quieto, nada para enviar" difere de "toda push falha". Relate a causa e sua correção conforme fornecida (por exemplo, chave rejeitada → hwip login, nenhum app conectado → faça login no app Hwip em um iPhone ou Android); hwip verify tem mais.
• Hwip: <device> changed its encryption key — … → não é uma falha: um dos dispositivos do usuário agora lista uma chave de criptografia diferente da que esta máquina havia fixado, e a nova chave é confiável. Mostrado uma vez, depois limpo. Relate como isso — um app reinstalado ou um novo telefone explica; se nem um nem outro explica, hwip trust mostra as impressões digitais para comparar com o app.

Perguntas (hwip_ask, o espelho AskUserQuestion) enviam push em todos os níveis, exceto mute.

O contexto que uma questão lacrada carrega (o diff git mascarado da sessão e as últimas linhas do terminal) não é um nível aqui. Se o usuário pedir para parar de enviá-lo, aponte-o para hwip ask-context off (este projeto) ou hwip ask-context off --global (todo projeto); hwip ask-context mostra qual se aplica.

Se a saída terminar com um bloco === Hwip rules — replace the Hwip rules from session start ===, o estado mudou e as regras que o hook SessionStart deu a esta sessão estão desatualizadas: siga esse bloco pelo resto da sessão, inclusive após a compactação. Session rules unchanged significa que a mudança não as afetou (por exemplo, normal ↔ loud); mantenha as que você tem. approve nunca altera as regras. Uma linha could not refresh significa que a mudança ainda se aplica, mas as regras não foram atualizadas — informe ao usuário que uma nova sessão as aplica.