Bagel-EW/brief-yourself

Brief Yourself 1.0.1｜Capa de Contexto Personal

Brief Yourself 1.0.1 es el producto actual, la entrada del Skill, la identidad del agente y la identidad activa del esquema. La schema_version actual es 1.0.1; la versión histórica 0.4 solo se conserva en artefactos antiguos y notas históricas, no como esquema activo.

Activación y Posicionamiento

Utiliza este Skill cuando el usuario quiera conocerse a sí mismo, permitir que el agente lo conozca mejor, revisar cambios recientes o disponer de información personal calibrada para una tarea descendente.

Brief Yourself es una Capa de Contexto Personal calibrada con la participación del usuario, compilada por propósito y portable a diferentes harnesses de agente. El Almacén de Contexto Personal (Personal Context Store) es la fuente canónica del contexto personal; la Vista de Congelación (Context View) es la entrada congelada para una tarea específica; el Parche de Contexto (Context Patch) es el candidato de retorno que el usuario revisa al finalizar la tarea.

Codex Memory, rollout, documentación del proyecto y otras memorias del harness solo pueden servir como evidencia candidata tras una autorización explícita. No pueden importarse automáticamente, sobrescribir el Almacén, convertirse en una Declaración confirmada ni ser fuente canónica. Brief Yourself no replica los flujos de rollout, consolidación, recuperación, hilo o inyección genérica de memoria.

No Objetivos y Límites Estrictos

• No es un almacén histórico universal, motor de búsqueda vectorial, diagnóstico psicológico ni determinación de "personalidad real".
• No convierte la Memoria del Harness en Contexto Personal ni realiza sincronización bidireccional silenciosa; auto_import_harness_memory debe ser false.
• La versión 1.0.1 solo implementa subject.type = person. El Contexto de Organización solo reserva límites de aislamiento a través del Envoltorio común, y no se implementa un Almacén de Contexto de Equipo en este Skill.
• No utiliza perfiles personales para tomar decisiones automatizadas de alto impacto (empleo, crédito, seguros, salud) sin autorización.
• No lee Contexto Personal real, datos de prueba privados ni materiales históricos, a menos que el usuario complete primero la autorización explícita de las fuentes para esta ronda.
• La información personal se escribe como Declaraciones declarativas, no como comandos que sobrescriban instrucciones futuras; los flujos y reglas operativas pertenecen al Skill o a la documentación del proyecto.

Contrato de Sesión: Primero Acordar, Luego Explorar

Al crear o actualizar un perfil, selecciona primero Profundidad, Evidencia y Ritmo. Antes de la primera pregunta exploratoria, muestra el Contrato de Sesión completo y espera a que el usuario lo acepte o ajuste; no solicites experiencias, juicios de valor ni otro contenido exploratorio antes de la aceptación.

El Contrato debe especificar al menos: objetivo; Profundidad, Evidencia y Ritmo; dimensiones cubiertas y excluidas; máximo de prompts, rondas de usuario y duración estimada; fuentes a leer y su alcance; entregables; si el Almacén Personal se archiva y si el consumidor descendente puede guardarlo aparte; rutas de pausa, salto y eliminación. Cuando el usuario solo dice "empezar", se usan los valores recomendados. La sesión actual finaliza al alcanzar cualquier límite superior o condición de parada; continuar explorando requiere establecer un nuevo Contrato.

Profundidad	Máx. prompts	Rondas usuario	Duración estimada
Rápida	5	2–3	5–10 minutos
Estándar (predet.)	8	3–4	15–25 minutos
Profunda	12	4–5	30–45 minutos

History-assisted (asistido por historial) es solo un modificador de Evidencia; debe heredar todos los límites superiores de la Profundidad seleccionada y no puede convertirse en una cuarta profundidad ni extender la sesión. Cuando el usuario muestre fatiga, pregunte cuántas preguntas quedan, indique que la sesión es demasiado larga, o el material existente ya sea suficiente para formar un perfil mínimo adecuado, detén inmediatamente las nuevas preguntas y sintetiza; no continues preguntando solo para completar el guion.

Flujo de Ejecución

1. Determinar la operación. Elegir crear/actualizar perfil, generar Vista de Tarea, revisar Parche, o Inspeccionar/Exportar; primero explica el propósito y el alcance mínimo necesario.
2. Obtener autorización de lectura (tarjeta de consentimiento). Antes de leer historial, archivos de proyecto, currículum, materiales públicos o Memoria del Harness, muestra la fuente, alcance, propósito, transmisión externa, ubicación de almacenamiento y método de eliminación según references/source-consent-and-disclosure.md, y espera autorización explícita. La tarjeta de consentimiento es la interfaz de consentimiento previa a la lectura, regida por esa referencia; es distinta del comando register-source, que es la entrada de registro de fuente a largo plazo después de la lectura y aprobación del usuario. La conversación actual y los materiales proporcionados voluntariamente por el usuario también deben registrar el alcance real de uso.
3. Recopilar evidencia según necesidad. Primero usa la respuesta actual y los materiales proporcionados voluntariamente por el usuario; el historial solo se lee según sea necesario para lagunas conocidas, no se importa en bloque. El contenido proveniente de la Memoria del Harness solo forma evidencia candidata, debe marcarse como pendiente de calibración y no puede convertirse directamente en una Declaración confirmada.
4. Entrevista y calibración. Sigue references/interview-and-calibration.md para gestionar el presupuesto; comienza con experiencias, elecciones y comportamientos específicos, y muestra periódicamente la Tarjeta de Calibración para que el usuario confirme, reformule, rechace o deje pendiente.
5. Formar candidatos a Declaración planos. El Almacén solo tiene un claims[]; domains[] son etiquetas, no una jerarquía física. Las nuevas percepciones son por defecto candidatos de Dominio con user_status: unreviewed, y no ascienden a Core en una sola sesión. El Resumen Core solo se deriva de Declaraciones confirmadas, aún vigentes y con respaldo transversal; no se almacena por separado.
6. Generar Vista congelada. Compila la Vista según el propósito, el sujeto/ejecutor/audiencia exactos y las Declaraciones mínimas necesarias; congela el objeto completo, source_revision, momento de creación, TTL y permisos. Los cambios posteriores en el Almacén no modifican silenciosamente las Vistas existentes.
7. Solo almacenar Parche temporalmente. Las nuevas percepciones de la tarea solo generan un Parche pending; las estrategias y el lenguaje desechable se colocan en task_strategies_not_for_merge. Revisa cada elemento según references/context-view-and-patch.md; el runtime solo puede aplicar el Parche después de que el usuario apruebe explícitamente el patch_id y la Propuesta específicos.

Reglas Mínimas para Evidencia y Percepciones

• fact (hecho), self_report (autoinforme), observation (observación), inference (inferencia) se registran por separado; no se reescribe una inferencia como un hecho.
• Se conservan la fuente de evidencia, contraevidencia, alcance de aplicación, cambios, contradicciones (Tensión) y unknowns; la ausencia de registro no significa que no haya ocurrido.
• Tensión y Desconocido siguen siendo entidades de primer nivel en el Almacén canónico actual y también pueden ingresar a la Vista como objetos congelados completos; no son solo de sesión de forma permanente. El esquema/runtime actual de Parche solo admite Propuestas de add, update, challenge, retire para Declaraciones; no hay entrada de adición o actualización para Tensión/Desconocido. Los nuevos hallazgos de la sesión solo pueden entregarse como "candidatos no persistidos" a la espera de un acuerdo explícito futuro; no pueden escribirse silenciosamente en el Almacén, disfrazarse de Declaraciones, insertarse en task_strategies_not_for_merge, ni afirmar que se han guardado a largo plazo. Las Tensiones/Desconocidos existentes en la migración/Almacén permanecen legibles y pueden incluirse en la Vista según sea necesario; las futuras entradas de escritura requieren esquema/runtime/aprobación adicionales y no se implementan en esta ronda.
• No se utilizan MBTI, DISC o una sola respuesta como sustituto de la evidencia; no se escriben como Declaraciones a largo plazo el progreso de una tarea única, palabras clave de una descripción de puesto, estrategias temporales o preferencias operativas del agente.
• Las nuevas percepciones ingresan primero al Dominio candidato; Core solo existe como calificación de resumen derivado, no puede ascenderse directamente desde una sola tarea. La escritura a largo plazo siempre pasa por la revisión del usuario.
• sensitivity describe el nivel de sensibilidad del contenido; disclosure describe la audiencia, el propósito y el permiso de persistencia aguas abajo; no son intercambiables. Por defecto se excluyen private y restricted.
• subject es fijo como person. team-agent u otros ejecutores/audiencias no autorizados explícitamente se rechazan por defecto; no se puede inferir autorización personal por "mismo espacio de trabajo".

Comandos de Runtime

El runtime registra 17 nombres de operación: 14 operaciones formales V0.4 se enrutan en los cinco grupos siguientes; 2 comandos de migración solo se usan en escenarios de migración; list es un alias compatible de list-patches, no una capacidad independiente. Los parámetros se rigen siempre por --help; esta entrada no presupone flags no verificados. No uses estos comandos para migrar o hacer dogfood en el Almacén real a menos que tengas autorización aparte. Para detalles completos de parámetros y efectos secundarios, consulta references/store-operations.md.

Ciclo de Vida del Almacén

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 crea un nuevo Almacén; validate realiza una validación completa sin corrección silenciosa; inspect muestra la revisión, los conteos y los Parches pendientes; derive-core-summary solo deriva un resumen no canónico a partir de Declaraciones confirmadas que cumplan las condiciones.

Registro de Fuentes

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

register-source es la única entrada de escritura para Fuentes de Evidencia; consent debe ser explicit. No es la interfaz de consentimiento de lectura: la tarjeta de consentimiento previa a la lectura se rige por references/source-consent-and-disclosure.md; este comando solo se ejecuta después de que el usuario haya autorizado la lectura y aprobado el registro a largo plazo.

Vista

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

create-view compila una Vista congelada; el alcance sensible y las restricciones se deciden en este paso mediante la divulgación y la aprobación del usuario; validate-view solo realiza validación (caducidad, propósito, nivel de sensibilidad, estructura de permisos), no modifica ni crea restricciones. No se actualiza después de la creación.

Parche

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 solo escribe en estado pending; apply-patch requiere la revisión del Parche específico, --approve y un actor confirmado; reject-patch no modifica el Contexto Canónico.

Exportación y Eliminación

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

export por defecto solo exporta public. purge es un olvido irreversible: primero ejecuta purge-plan para obtener una vista previa y recibe --plan-token; al ejecutar, también se necesitan --confirmed-by y --approve; si el Almacén cambia después de la vista previa, el token se invalida. Esta entrada no proporciona ejemplos de ejecución que omitan estas restricciones; los límites completos están en references/store-operations.md.

Enrutamiento de Migración Histórica (solo lectura para escenarios de migración)

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

Estos dos comandos solo atienden la migración histórica V0.2→V0.3 y V0.3→1.0.1; no forman parte de las capacidades de tarea normales. Primero lee references/migration-v0.3-to-v1.0.1.md y úsalos según sus límites de vista previa, revisión, guardado aparte y reversión. migrate-v02 reescribe la ruta de entrada, por lo que solo debe ejecutarse en una copia explícita creada por el usuario; V0.3→1.0.1 solo permite vista previa de solo lectura.

Adaptador de Archivo C: Solo Recibe Vistas Congeladas

El scripts/adapters/codex_file_adapter.py del paquete C es un Adaptador de Archivo unidireccional. Solo lee un JSON de Vista congelada ya generado, valida el Envoltorio, TTL, sujeto, propósito, allowed_use, y que cada Declaración incluida autorice tanto principal.id como cada destinatario en audience[]; en caso de fallo, cierra de forma segura (fail-closed) sin imprimir el texto personal rechazado. No lee el Almacén de Contexto Personal, Codex Memory, rollout ni recursos de red; no escribe de vuelta al Almacén, Memoria del Harness ni ningún Contexto a largo plazo; la salida opcional tampoco puede sobrescribir la Vista de entrada.

Se han verificado los siguientes comandos conceptuales según el --help real de C. --expected-audience es un enlace de subconjunto repetible proporcionado por el llamante: cada type:id esperado debe existir en view.audience congelado, pero el llamante no necesita enumerar toda la audiencia, por lo que no es una aserción de igualdad/exhaustividad de audiencia. Este enlace del llamante no cambia la invariante de seguridad: independientemente de si se pasa este parámetro, el adaptador aún debe verificar para cada Declaración incluida que la divulgación cubra tanto principal.id como todos los IDs de destinatario de la audiencia en el Envoltorio de la Vista, y verificar el propósito; el parámetro de subconjunto no puede ampliar la divulgación. --purpose-approved solo indica que el propósito específico de esta ejecución ha sido aprobado explícitamente:

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

La salida del adaptador es el resultado de adaptación Markdown/JSON para la tarea actual; no es un nuevo Almacén, Memoria ni credencial de reescritura; al finalizar la tarea, solo se genera un Parche pending. La salida Markdown compacta aún conserva user_status, confidence, status, scope aplicable, evidence_refs, counterevidence_refs y campos de tiempo clave no vacíos de cada Declaración; solo muestra el ID de la fuente, no expande el texto de la evidencia, notas ni fuente sin procesar. Las Declaraciones no revisadas se muestran explícitamente como review=unreviewed / review=unresolved y no se comprimen en hechos determinados incondicionalmente. El Almacén y el Adaptador comparten el núcleo de validación de Vistas sin Almacén de scripts/view_validation.py; cada uno agrega solo la referencia de fuente del Almacén o la verificación de enlace del llamante sobre esa base.

Enrutamiento de Referencias

El paquete oficial solo conserva las siguientes 7 referencias, cada una accesible desde esta entrada; el momento de lectura es el siguiente:

• references/interview-and-calibration.md: Se lee antes de comenzar la entrevista. Contrato de Sesión, presupuesto de tres niveles, Mapa de Preguntas, Tarjeta de Calibración, parada por fatiga y clasificación de Declaraciones.
• references/source-consent-and-disclosure.md: Se lee antes de cualquier lectura de historial/proyectos/currículum/Memoria del Harness. Única fuente factual de consentimiento y divulgación: tarjeta de consentimiento, evidencia candidata, sensibilidad, divulgación, aislamiento persona/equipo y límites de alto impacto. La tarjeta de consentimiento pertenece aquí, no a register-source.
• references/context-view-and-patch.md: Se lee al compilar una Vista o revisar un Parche. Envoltorio de Contexto de la versión actual, objeto congelado completo, TTL, coincidencia de divulgación, almacenamiento temporal y aprobación de Parches.
• references/harness-boundaries.md: Se lee al tratar con límites de Memoria del Harness o el Adaptador de Archivo. Límites entre Memoria del Harness, Contexto Personal y Contexto de Tarea, y reglas de enlace de envoltorio/divulgación y audiencia esperada del Adaptador de Archivo.
• references/personal-context-model.md: Se lee cuando se necesita confirmar la semántica de la estructura del Almacén. Entidades de primer nivel del Almacén de Contexto Personal, modelo de evidencia, límites de retorno de Vista/Parche y semántica de versiones.
• references/store-operations.md: Se lee antes de ejecutar cualquier comando de runtime. Parámetros, efectos secundarios, limitaciones del sistema de archivos, límites de purga y métodos de recuperación de las 14 operaciones 1.0.1 y 2 comandos de migración.
• references/migration-v0.3-to-v1.0.1.md: Solo se lee en escenarios de migración histórica V0.3→1.0.1. Vista previa de solo lectura, metadatos y ruta de migración sin cadena; el antiguo 0.4 solo se conserva como identificador de entrada histórica y artefacto antiguo.

Enrutamiento de Activos

Tres plantillas 1.0.1 emparejadas con sus esquemas homónimos, se leen al construir o validar el objeto correspondiente:

• assets/templates/personal-context-store-v1.0.1.json: Línea base de estructura del Almacén, usada junto con assets/schemas/personal-context-store-v1.0.1.schema.json; se consulta al construir manualmente o validar el Almacén después de init.
• assets/templates/context-view-v1.0.1.json: Línea base de estructura de Vista congelada, usada junto con assets/schemas/context-view-v1.0.1.schema.json; se consulta al compilar o validar una Vista.
• assets/templates/context-patch-v1.0.1.json: Línea base de estructura de Parche, usada junto con assets/schemas/context-patch-v1.0.1.schema.json; se consulta al almacenar temporalmente o revisar un Parche.

Las plantillas históricas V0.3 y las referencias antiguas se han movido fuera del paquete oficial y se conservan en el directorio archive/1.0.1-moved-out/ del proyecto; los artefactos antiguos 0.4 solo se conservan en releases/ y no forman parte del protocolo actual; no deben incluirse en el ZIP de publicación.

Entrega y Mensaje Final

Según la operación, entrega un Informe Humano, Declaraciones candidatas, Tensión/Desconocido, Vista congelada o Parche pending, y enumera el alcance de las fuentes, los elementos no cubiertos, los límites de sensibilidad y las preguntas que vale la pena verificar la próxima vez. Al finalizar, deja claro: este es un perfil de trabajo basado en los materiales autorizados actuales, hasta el momento; el usuario puede corregir, restringir el uso, rechazar o eliminar cualquier elemento.