Comentar sobre este guia

Protocolar

Core

Protocolar means processing concrete operational content into the right execution or knowledge layer.

The input is usually messy: audio, rough text, notes from a meeting, event operation details, or Hugo thinking out loud.

Protocolar must be calm, question-driven, and interactive. It is one of the highest-leverage moments for Hugo and Codex to think together, because spending Hugo's time now can make future operations flow much faster and with less rework.

Mandatory Human Approval (Aprovação Prévia Obrigatória)

Never execute or write blindly. In the protocoling workflow, the agent must never act fully autonomously without human approval.

When handling any protocoling request:

  1. Explicit Detection: If not explicitly invoked, recognize the context and announce: "Estou entendendo que a gente está falando de protocolagem."
  2. Declare Meta: State the operational goal in 1 line (> Meta que estou assumindo: ...).
  3. Present Proposed Action: Explain what you intend to do before touching any file or sheet:
    • Specific Suprema tasks (timing, role, activity, description, procedure).
    • Existing KB articles to update (prioritizing existing docs over creating new KBs).
    • Justification if a new KB is strictly necessary (always prefer avoiding new KBs if it fits in Suprema or existing guides).
  4. Request Human OK: Ask for human approval (using Quick Voting A/B/C or "Proposta: X. Ok?") before writing anything.
  5. Execute & Sweep: Only after human approval: write to Suprema/KB, execute the mandatory Conflict & Deprecation Scan, record decision trace, commit and push.

Do not protocolar with less than 90% confidence in the classification, target destination, owner, timing, and operational consequence. When confidence is below that threshold, ask concise questions and process only the parts that are clear.

Classify each piece as:

Then save it in the right place.

Effectiveness and Less Verb Rule

The goal of protocolar is not to create more articles, more tasks, or more documentation. The goal is to find the best way to make the thing happen.

Before creating anything new, ask:

Whenever possible, prefer consolidating, merging, adapting, shortening, or creating nothing.

For materials humans need to read and execute, write the minimum sufficient text: clear, direct, and without excess wording. Documentation is only good if a real person can read it, understand it, and act.

Clarity Before Brevity

Less wording does not mean text that is too short.

The protocol must be as short as possible, but as complete as necessary for a person to understand and execute without hidden context.

Especially for concepts, principles, and new decisions, preserve:

If the text is short but ambiguous, it is not good yet. If the text is longer but protects execution, training, or future judgment, it may be right.

The goal is density: every sentence must carry function.

Non-Duplication Rule

Do not duplicate.

Before creating anything, check whether the same or similar item already exists.

Then decide:

This applies to:

Escopo entre eventos

Antes de gravar um achado numa Suprema (ICDB, MRZPR, RAV, Venda Sem Medo ou outra), classificar e dizer na proposta ao Hugo:

A decisão sai de kb/events/perfis-eventos-suprema.md (dias, equipe, venda, Premium, certificado, lojinha, transmissão). Na dúvida, perguntar ao Hugo. Nunca escrever direto na Suprema de outro evento, e não criar Suprema-mãe nem sincronização entre abas.

Conflict & Deprecation Scan

When a protocoling request introduces a prohibition, change in tool, corrective policy, or superseded method (e.g., "não usar X", "nunca fazer Y", "trocar fornecedor A por B"):

  1. Active Repository Scan: Run an active search (grep/ripgrep) across kb/ and projects/ for any mentions of the prohibited or superseded practice/tool/vendor.
  2. Suprema Inspection: Check if any existing Suprema tasks reference the superseded approach (using the read-only helper or text search).
  3. Revocation & Alignment: Revoke, align, or eliminate conflicting instructions so the ecosystem never has an active procedure contradicting the new rule.
  4. Report Findings: Always state in the output whether previous conflicting occurrences were found and updated, or confirmed clean.

Tarefa

A task is an executable action with owner/timing/output.

Examples:

Process Task

  1. Infer or confirm:
    • etapa
    • dia
    • horario
    • time_resp
    • atividade
    • descricao
    • procedure
    • source
  2. Check for duplicates or similar rows before writing.
  3. If an existing task only needs adjustment, update it instead of adding a new row.
  4. Add to Suprema/checklist when operational and not already handled.
  5. Mirror locally only when reusable.

Suprema is an execution checklist: only add a row when someone needs to do, check, or remember something at a clear operational moment. Preparation, posture, speaking guidance, training notes, and facilitation principles should go first into procedure/training docs, not Suprema, unless there is a derived practical action with owner and timing.

During this protocolar cycle, any guidance about ASSISTENTE4 or ICDB online transmission goes to KB/process docs, not Suprema, unless Hugo explicitly asks for a Suprema row.

For ICDB Suprema, prefer:

rz-coo/agents/events-NEHEMIAH/scripts/append_suprema_task.py

To read or inspect ICDB Suprema before/after appending, use the read-only helper:

rz-coo/agents/events-NEHEMIAH/scripts/read_suprema.py

Do not use ad hoc Python snippets for normal Suprema reading/verification when the helper covers the need.

Important: horario must be Google Sheets time number, not text.

For role names in Suprema/KB, keep the standard role variable stable. Use ASSISTENTE3, not specialized variable names like ASSISTENTE3_LOJA. Explain the function in the activity/description/procedure, for example loja, comercial, expositores, inventario, or vendas.

Procedimento

A procedure explains exactly how a task is done.

Create/update a Markdown procedure when the content answers "how should this task be executed?"

Video Tutorials (Google Drive & Local Files)

When Hugo provides video/audio tutorials as input for protocoling:

Procedure Boundary Rule

Do not group procedures only because they involve the same person, project, or broad commercial theme.

Group content into one procedure only when it shares the same operational function, execution moment, owner logic, and output.

Prefer separate procedures when the work has different purposes or execution contexts, even if the same person is involved.

Example from ICDB:

They can all involve treinadora/supervisao, but they should not be merged because they answer different operational questions.

When unsure, propose the split before editing.

Procedure should include:

Then link it in Suprema via procedure.

When the procedure lives under kb/ and is publishable, use the public KB URL in Suprema instead of the local file path:

https://app.reorganize.com.br/kb/{path-under-kb-without-.md}?t=organizartransforma

Example:

kb/events/icdb/guia-equipe.md becomes https://app.reorganize.com.br/kb/events/icdb/guia-equipe?t=organizartransforma.

Keep local repo links inside Markdown docs when that is more useful for editing, but use public KB links for people who will execute tasks outside the repo.

Principio

A principle is a general rule used for training, expectation alignment, or future judgment.

Examples:

Principles go to the correct training/alignment doc:

Do not add principles to Suprema unless they imply an action.

Commission Clarity

Be precise about who receives commission.

For ICDB expositores: the expositor does not receive commission. The treinadora or coordenadora may receive commission for indicating, captando, or helping close an approved expositor.

If a note mentions commission ambiguously, clarify the payer/receiver before documenting or adding to Suprema.

Generalize

Always ask:

Is this only for this edition, or should it become a standard?

If reusable:

If specific:

Sync and Push Confirmation

After protocoling an item into the minimum necessary destination, evaluate whether mirroring it into another layer and publishing the repository change are clearly part of the requested workflow.

This rule does not override repository instructions, database write policy, financial/operational approval thresholds, or any requirement for explicit approval before a sensitive action.

Inbox First

When an audio/text contains many mixed items, use kb/inbox/protocolar.md first.

Use one stable protocolar inbox by default. Do not create a new inbox file for each destination unless Hugo explicitly asks for a separate inbox.

Flow:

  1. classify into task/procedure/principle in the inbox;
  2. mark the original raw/source with <!-- PROTOCOLAR_INBOX: item-id em kb/inbox/protocolar.md -->;
  3. wait for Hugo's OK when needed;
  4. apply to Suprema/KB/playbook/training docs;
  5. change the raw/source marker to <!-- PROTOCOLADO: item-id destino data -->;
  6. remove the item from the inbox after it is applied.

Do not mark raw/source as PROTOCOLADO while the item is only awaiting approval in the inbox.

For simple clear edits, go directly to the target instead of using inbox.

Use a_aprovar only when there is an actual open decision, ambiguity, or risk. If the task/procedure/principle is clear and Hugo has asked to protocolar, either process directly or put it in the inbox as pronto_para_processar, not a_aprovar.

Search First

Before creating a procedure, search:

  1. kb/
  2. relevant project playbook/
  3. relevant project sources/raw/
  4. kb/sources/tutorials-drive-inventory.md
  5. Drive folder @Equipe-RZ TUTORIAIS
  6. Drive playbooks/docs with short metadata search first

Do not open large docs unless needed.

Ask When Needed

Ask Hugo if:

Output

After protocoling, say briefly: