Brief Yourself 1.0.1｜Camada de Contexto Pessoal

Brief Yourself 1.0.1 é a identidade do produto atual, ponto de entrada da Skill, identidade do Agente e identidade ativa do esquema. A schema_version atual é 1.0.1; a versão histórica 0.4 permanece apenas em artefatos antigos e documentação histórica, não como esquema ativo.

Gatilho e Posicionamento

Use esta Skill quando o usuário quiser se conhecer, fazer com que o Agente o entenda melhor, revisar mudanças recentes, ou desejar usar informações pessoais calibradas em uma tarefa downstream.

Brief Yourself é uma Camada de Contexto Pessoal que é calibrada com a participação do usuário, compilada por propósito e portátil para diferentes harnesses de Agentes. O Personal Context Store é a fonte canônica do contexto pessoal; Context View é a entrada congelada para uma tarefa específica; Context Patch é o candidato de retorno submetido à aprovação do usuário após a tarefa.

Codex Memory, rollout, documentação de projeto e outras memórias de harness só podem ser usadas como evidência candidata após autorização explícita. Elas não podem ser importadas automaticamente, sobrescrever o Store, tornar-se confirmed Claims ou tornar-se fonte canônica. Brief Yourself não replica processos de rollout, consolidação, recuperação, thread ou injeção genérica de memória.

Não Objetivos e Limites Rígidos

Não é um histórico genérico, busca vetorial, diagnóstico psicológico ou determinação de "personalidade real".
Não transforma Harness Memory em Contexto Pessoal, nem faz sincronização bidirecional silenciosa; auto_import_harness_memory deve ser false.
A versão 1.0.1 atual implementa apenas subject.type = person. O Organizational Context só reserva limites de isolamento através do Envelope comum, não sendo implementado um Team Context Store nesta Skill.
Não usa perfis pessoais para decisões automatizadas de alto impacto (emprego, crédito, seguro, saúde) sem autorização.
Não lê Contexto Pessoal real, dados de teste privados ou materiais históricos, a menos que o usuário conclua a autorização explícita de fontes nesta rodada.
Informações pessoais são escritas como Claims declarativas, não como comandos que sobrescrevem instruções futuras; regras de processo e operação pertencem à Skill ou documentação do projeto.

Contrato de Sessão: Primeiro Combinar, Depois Explorar

Ao criar ou atualizar um perfil, primeiro escolha Depth, Evidence e Pace. Antes da primeira pergunta exploratória, exiba o Contrato de Sessão completo e aguarde que o usuário aceite ou ajuste; antes da aceitação, não solicite experiências, julgamentos de valor ou outros conteúdos exploratórios.

O Contrato deve explicar no mínimo: objetivo; Depth, Evidence, Pace; dimensões cobertas e excluídas; máximo de prompts, rodadas do usuário e tempo estimado; fontes a serem lidas e seu escopo; entregáveis; se o Personal Store será arquivado, se o downstream pode salvar separadamente; caminhos para pausar, pular e excluir. Quando o usuário disser apenas "iniciar", use os valores recomendados. A Sessão atual termina ao atingir qualquer limite superior ou condição de parada; continuar a exploração exige um novo Contrato.

Depth	Máx. de Prompts	Rodadas do Usuário	Tempo Estimado
Quick (Rápido)	5	2–3	5–10 minutos
Standard (Padrão)	8	3–4	15–25 minutos
Deep (Profundo)	12	4–5	30–45 minutos

History-assisted (com auxílio de histórico) é apenas um modificador de Evidence, deve heradar todos os limites superiores da Depth escolhida, não se tornando uma quarta profundidade ou prolongando a Sessão. Quando o usuário demonstrar cansaço, perguntar quantas perguntas faltam, der feedback de que está demorando muito, ou o material já for suficiente para formar um perfil mínimo adequado, pare imediatamente de fazer novas perguntas e faça a síntese; não continue perguntando apenas para completar o script.

Fluxo de Execução

Determinar a operação. Escolha criar/atualizar perfil, gerar Task View, revisar Patch, ou Inspecionar/Exportar; primeiro explique o propósito e o escopo mínimo necessário.
Obter autorização de leitura (Cartão de Autorização). Antes de ler históricos, arquivos de projeto, currículos, materiais públicos ou Harness Memory, siga references/source-consent-and-disclosure.md para exibir fonte, escopo, propósito, transferência externa, local de armazenamento e método de exclusão, e aguarde autorização explícita. O Cartão de Autorização é a interface de consentimento antes da leitura, regida por essa referência; é diferente do comando register-source — register-source é o ponto de entrada para registro de fontes aprovadas pelo usuário após a leitura. O escopo real de uso também deve ser registrado na conversa atual e nos materiais fornecidos pelo usuário.
Coletar evidências conforme necessário. Primeiro use a resposta atual e os materiais fornecidos pelo usuário; o histórico só é lido conforme a necessidade para preencher lacunas conhecidas, sem importação em lote. Conteúdo vindo da Harness Memory forma apenas evidência candidata, deve ser marcado como "pending calibration" (a calibrar), e não pode se tornar diretamente um Claim confirmado.
Entrevista e Calibração. Siga references/interview-and-calibration.md para controlar o orçamento; comece por experiências, escolhas e comportamentos concretos, exibindo periodicamente um Cartão de Calibração para que o usuário confirme, reescreva, rejeite ou deixe como pendente.
Formar Claims planos candidatos. O Store tem apenas um claims[]; domains[] são rótulos, não hierarquia física. Novos entendimentos são, por padrão, candidatos de Domínio com user_status: unreviewed, e não sobem para Core em uma única Sessão. O Core Summary só pode ser derivado de Claims já confirmados, ainda válidos e com suporte em múltiplos cenários; não é armazenado separadamente.
Gerar View congelada. Compile a View com base no propósito, no sujeito/executor/público exatos e nos Claims mínimos necessários; o objeto completo, source_revision, timestamp de criação, TTL e permissões devem ser congelados juntos. Mudanças posteriores no Store não alteram silenciosamente a View existente.
Apenas armazenar Patch temporariamente. Novos entendimentos da tarefa geram apenas um Patch pending, e estratégias e frases únicas vão para task_strategies_not_for_merge. Siga references/context-view-and-patch.md para revisão item por item; somente após o usuário aprovar explicitamente o patch_id e a Proposta, o runtime pode fazer o apply.

Regras Mínimas para Evidências e Entendimentos

fact, self_report, observation, inference são registrados separadamente; inferências não são reescritas como fatos.
Mantenha a fonte da evidência, contra-evidência, escopo de aplicação, mudanças, contradições (Tension) e unknown; ausência de registro não significa que não ocorreu.
Tension e Unknown ainda são entidades de topo do Store canônico atual, podendo também entrar na View como objetos congelados completos; não são exclusivos da sessão temporária. O Patch schema/runtime atual oferece suporte apenas a add, update, challenge, retire para Claims, sem entrada para adicionar/atualizar Tension/Unknown. Novas descobertas da sessão só podem ser entregues como "candidatos não persistidos" e aguardar acordo explícito futuro; não podem ser gravados silenciosamente no Store, disfarçados de Claims, colocados em task_strategies_not_for_merge, ou declarados como salvos permanentemente. Tension/Unknown existentes no store/migração permanecem legíveis e podem ser incluídos na View conforme necessário; futuras entradas de escrita exigem outro schema/runtime/aprovação, não implementadas nesta rodada.
Não use MBTI, DISC ou uma única resposta como substituto de evidência; não escreva itens como progresso de uma única tarefa, palavras-chave de JD, estratégias temporárias ou preferências de operação do Agente como Claims de longo prazo.
Novos entendimentos vão primeiro para um Domínio candidato; Core é apenas uma qualificação derivada para resumo, não pode ser promovido por uma única tarefa. A escrita de longo prazo sempre passa pela revisão do usuário.
sensitivity descreve o nível de sensibilidade do conteúdo; disclosure descreve público, propósito e permissões de persistência downstream; um não substitui o outro. O padrão exclui private e restricted.
subject é fixo como person. team-agent ou outros executores/públicos não autorizados explicitamente são rejeitados por padrão; o fato de estarem no "mesmo workspace" não implica autorização pessoal.

Comandos do Runtime

O runtime registra 17 nomes de operação: 14 operações formais V0.4 são roteadas nos cinco grupos abaixo; 2 comandos de migração são usados apenas em cenários de migração; list é um alias de compatibilidade para list-patches, não uma capacidade independente. Os parâmetros são sempre regidos por --help; esta entrada não pressupõe flags que não foram verificadas. Não use esses comandos para migração ou dogfood do Store real, a menos que haja autorização separada. Detalhes dos parâmetros e efeitos colaterais estão em references/store-operations.md.

Ciclo de Vida do Store

python scripts/context_store.py init --help
python scripts/context_store.py validate --store <store>
python scripts/context_store.py inspect --store <store>
python scripts/context_store.py derive-core-summary --help

init cria um novo Store; validate faz validação completa, sem correção silenciosa; inspect exibe revisão, contagens e Patches pendentes; derive-core-summary deriva um resumo não canônico apenas de Claims confirmados elegíveis.

Registro de Fonte

python scripts/context_store.py register-source --help

register-source é o único ponto de entrada para escrever uma Evidence Source; consent deve ser explicit. Não é uma interface de autorização de leitura: o Cartão de Autorização antes da leitura é regido por references/source-consent-and-disclosure.md; este comando só é executado após o usuário ter autorizado a leitura e aprovado o registro de longo prazo.

View

python scripts/context_store.py create-view --help
python scripts/context_store.py validate-view --help

create-view compila uma View congelada; o escopo sensível e as restrições são decididos nesta etapa via disclosure e aprovação do usuário; validate-view apenas valida (expiração, propósito, nível de sensibilidade, estrutura de permissões), não modifica nem cria restrições. Após a criação, não é atualizado.

Patch

python scripts/context_store.py stage-patch --help
python scripts/context_store.py list-patches --help
python scripts/context_store.py apply-patch --help
python scripts/context_store.py reject-patch --help

stage-patch escreve apenas como pending; apply-patch exige tanto a revisão específica do Patch quanto --approve e o ator confirmado; reject-patch não altera o Contexto Canônico.

Exportação e Exclusão

python scripts/context_store.py export --help
python scripts/context_store.py purge-plan --help
python scripts/context_store.py purge --help

export exporta apenas public por padrão. purge é um esquecimento irreversível: primeiro execute purge-plan para pré-visualização e obter o --plan-token; na execução, ainda são necessários --confirmed-by e --approve; se o Store sofrer qualquer alteração após a pré-visualização, o token se torna inválido. Esta entrada não fornece exemplos executáveis que contornem essas restrições; os limites completos estão em references/store-operations.md.

Rotas de Migração Histórica (apenas leitura em cenários de migração)

python scripts/context_store.py migrate-v02 --help
python scripts/context_store.py preview-migrate-v03 --help

Esses dois comandos servem apenas para as migrações históricas V0.2 → V0.3 e V0.3 → 1.0.1, não são capacidades de tarefas regulares; leia primeiro references/migration-v0.3-to-v1.0.1.md e use dentro de seus limites de pré-visualização, revisão, salvamento separado e reversão. migrate-v02 reescreverá o caminho de entrada, execute apenas em cópias explícitas criadas pelo usuário; V0.3 → 1.0.1 permite apenas pré-visualização somente leitura.

C File Adapter: Apenas Recebe View Congelada

O scripts/adapters/codex_file_adapter.py no pacote C é um File Adapter unidirecional. Ele apenas lê um JSON de View congelada já gerado, valida o Envelope, TTL, sujeito, propósito, allowed_use, e se cada Claim incluído também autoriza principal.id e cada recipiente em audience[]; em caso de falha, fecha-se sem imprimir o conteúdo pessoal rejeitado. Ele não lê o Personal Context Store, Codex Memory, rollout ou recursos de rede; não escreve de volta no Store, Harness Memory ou qualquer Contexto de longo prazo; a saída opcional também não pode sobrescrever a View de entrada.

Os seguintes comandos conceituais foram verificados com o --help real do C. --expected-audience é uma vinculação de subconjunto repetível fornecida pelo chamador: cada tipo:id esperado deve existir em view.audience congelado, mas o chamador não precisa enumerar todo o público; portanto, não é uma asserção de igualdade/exaustividade de público. Essa vinculação do chamador não altera as invariantes de segurança: independentemente de o parâmetro ser passado, o adaptador ainda deve verificar, para cada Claim incluído, se o disclosure cobre tanto principal.id quanto todos os IDs de destinatários do público no Envelope da View, além de verificar o propósito; o parâmetro de subconjunto não pode relaxar o disclosure. --purpose-approved indica apenas que o propósito específico desta execução foi explicitamente aprovado:

python scripts/adapters/codex_file_adapter.py --view <view.json> --expected-purpose <purpose> --expected-task <task> --expected-principal-id <principal-id> --expected-audience tipo:id --allowed-use <allowed-use> --purpose-approved

A saída do Adapter é o resultado da adaptação em Markdown/JSON para a tarefa atual, não um novo Store, Memory ou credencial de retorno; ao final da tarefa, apenas um Patch pending é gerado. A saída Markdown compacta ainda mantém user_status, confidence, status, scope aplicável, evidence_refs, counterevidence_refs e campos de tempo-chave não vazios de cada Claim; ela exibe apenas o ID da fonte, sem expandir o texto da evidência, notas ou source raw. Claims não revisados são exibidos explicitamente como review=unreviewed / review=unresolved, não sendo comprimidos em fatos determinísticos incondicionais. O Store e o Adapter compartilham o kernel de validação de View sem Store de scripts/view_validation.js; cada um adiciona apenas referências de fonte do Store ou verificações de vinculação do chamador.

Referências (References)

O pacote oficial mantém apenas as seguintes 7 referências, cada uma acessível a partir desta entrada; o momento de leitura é indicado:

references/interview-and-calibration.md: Leia antes de iniciar a entrevista. Contrato de Sessão, três níveis de orçamento, Mapa de Perguntas, Cartão de Calibração, parada por cansaço e classificação de Claims.
references/source-consent-and-disclosure.md: Leia antes de qualquer leitura de histórico/projeto/currículo/Harness Memory. Fonte única para consentimento e divulgação: Cartão de Autorização, evidência candidata, sensibilidade, disclosure, isolamento pessoa/equipe e limites de alto impacto. O Cartão de Autorização pertence aqui, não a register-source.
references/context-view-and-patch.md: Leia ao compilar uma View ou revisar um Patch. Envelope de Contexto da versão atual, objeto congelado completo, TTL, correspondência de disclosure, armazenamento temporário e aprovação de Patches.
references/harness-boundaries.md: Leia ao lidar com limites de Harness Memory ou File Adapter. Limites entre Harness Memory, Personal Context e Task Context, além das regras de envelope/disclosure e vinculação de expected-audience para o File Adapter.
references/personal-context-model.md: Leia quando precisar confirmar a semântica da estrutura do Store. Entidades de topo do Personal Context Store, modelo de evidência, limites de retorno de View/Patch e semântica de versão.
references/store-operations.md: Leia antes de executar qualquer comando do runtime. Parâmetros, efeitos colaterais, limites do sistema de arquivos, limites de purge e métodos de recuperação para todas as 14 operações 1.0.1 e 2 comandos de migração.
references/migration-v0.3-to-v1.0.1.md: Leia apenas em cenários de migração histórica V0.3 → 1.0.1. Preview somente leitura e metadata-only, e rota de migração sem encadeamento; o antigo 0.4 é mantido apenas como entrada histórica e identificador de artefato antigo.

Assets (Recursos)

Três templates 1.0.1 emparelhados com seus respectivos schemas; leia-os ao construir ou validar o objeto correspondente:

assets/templates/personal-context-store-v1.0.1.json: Linha de base da estrutura do Store, emparelhado com assets/schemas/personal-context-store-v1.0.1.schema.json; consulte ao construir manualmente ou validar o Store após init.
assets/templates/context-view-v1.0.1.json: Linha de base da estrutura da View congelada, emparelhado com assets/schemas/context-view-v1.0.1.schema.json; consulte ao compilar ou validar uma View.
assets/templates/context-patch-v1.0.1.json: Linha de base da estrutura do Patch, emparelhado com assets/schemas/context-patch-v1.0.1.schema.json; consulte ao armazenar temporariamente ou revisar um Patch.

Templates V0.3 históricos e referências antigas foram movidos para fora do pacote oficial, salvos no archive/1.0.1-moved-out/ do projeto; artefatos antigos 0.4 são mantidos apenas em releases/, não fazem parte do protocolo atual e não devem ser colocados no ZIP de lançamento.

Entrega e Mensagem Final

De acordo com a operação, entregue: Human Brief, Claims candidatos, Tension/Unknown, View congelada ou Patch pending, e liste o escopo das fontes, itens não cobertos, limites de sensibilidade e perguntas a serem validadas na próxima vez. Ao final, deixe claro: este é o perfil de trabalho atual, baseado nos materiais autorizados até este momento; o usuário pode corrigir, limitar o uso, rejeitar ou excluir qualquer item.

Bagel-EW/brief-yourself

O que é brief-yourself?

Perguntar na sua IA favorita

Documentação