Bagel-EW/brief-yourself

Brief Yourself 1.0.1｜Couche de Contexte Personnel

Brief Yourself 1.0.1 est le produit, le point d'entrée de la compétence, l'identité de l'agent et l'identité du schéma actif. La schema_version actuelle est 1.0.1 ; l'historique 0.4 est conservé uniquement dans les anciens artefacts et la documentation historique, pas comme schéma actif.

Déclenchement et Positionnement

Utilisez cette compétence lorsque l'utilisateur souhaite se connaître lui-même, permettre à l'agent de mieux le connaître, réviser les changements récents, ou utiliser des informations personnelles calibrées dans une tâche en aval.

Brief Yourself est une Couche de Contexte Personnel (Personal Context Layer) calibrée avec la participation de l'utilisateur, compilée par usage et portable vers différents environnements d'agent (Agent harness). Le Personal Context Store est la source canonique du contexte personnel ; la Context View est une entrée gelée pour une tâche donnée ; le Context Patch est un flux de retour candidat, soumis à l'approbation de l'utilisateur après la tâche.

Codex Memory, rollout, la documentation du projet et les autres mémoires du harness ne peuvent être utilisés comme preuves candidates qu'après une autorisation explicite. Ils ne peuvent pas être importés automatiquement, ni écraser le Store, ni devenir des Claim confirmées, ni être des sources canoniques. Brief Yourself ne reproduit pas les processus de rollout, de consolidation, de récupération, de threads ou d'injection de mémoire générique.

Non-Objectifs et Limites Strictes

• Ce n'est pas une base d'historique universelle, une recherche vectorielle, un diagnostic psychologique ou un jugement de « personnalité réelle ».
• Ne transforme pas la mémoire du Harness en Contexte Personnel, et n'effectue pas de synchronisation bidirectionnelle silencieuse ; auto_import_harness_memory doit être false.
• La version 1.0.1 implémente uniquement subject.type = person. Le Contexte Organisationnel (Organization Context) ne réserve qu'une frontière d'isolement via une enveloppe commune et n'est pas implémenté dans cette compétence (pas de Team Context Store).
• N'utilise pas de profils personnels pour des décisions automatisées à fort impact (emploi, crédit, assurance, médical) sans autorisation.
• Ne lit pas le Contexte Personnel réel, les données de test privées ou les documents historiques, sauf si l'utilisateur a d'abord effectué une autorisation de source explicite pour cette session.
• Les informations personnelles sont rédigées comme des Claim déclaratives, et non comme des commandes qui écraseraient les instructions futures ; les règles de processus et d'opération appartiennent à la compétence ou à la documentation du projet.

Contrat de Session : D'abord l'Accord, puis l'Exploration

Pour établir ou mettre à jour un profil, commencez par choisir la Profondeur (Depth), les Preuves (Evidence) et le Rythme (Pace). Avant la première question d'exploration, affichez complètement le Contrat de Session, et attendez que l'utilisateur l'accepte ou l'ajuste. Ne demandez pas d'expériences, de jugements de valeur ou autre contenu d'exploration avant l'acceptation.

Le Contrat doit au minimum indiquer : l'objectif ; la Profondeur, les Preuves, le Rythme ; les dimensions couvertes et exclues ; le nombre maximum de prompts, de tours utilisateur et la durée estimée ; les sources prévues pour la lecture et leur étendue ; les livrables ; si le Store personnel sera archivé et si la tâche en aval pourra enregistrer séparément ; les chemins pour suspendre, ignorer ou supprimer. Si l'utilisateur dit simplement « commence », utilisez les valeurs recommandées. La session se termine lorsque l'une des limites ou conditions d'arrêt est atteinte ; toute exploration supplémentaire nécessite un nouveau contrat.

Profondeur	Prompts max	Tours utilisateur	Durée estimée
Rapide (Quick)	5	2–3	5–10 minutes
Standard (par défaut)	8	3–4	15–25 minutes
Approfondie (Deep)	12	4–5	30–45 minutes

History-assisted est un modificateur de preuve (Evidence modifier) qui doit hériter de toutes les limites de la Profondeur choisie ; il ne peut pas devenir une quatrième profondeur ni prolonger la session. Si l'utilisateur montre des signes de fatigue, demande combien de questions restent, trouve que c'est trop long, ou si le matériel existant est suffisant pour former un portrait minimal adéquat, arrêtez immédiatement les nouvelles questions et faites la synthèse ; ne continuez pas à interroger pour terminer le script.

Flux de Travail

1. Déterminez l'opération. Choisissez de créer/mettre à jour un profil, générer une Vue de Tâche (Task View), réviser un Patch (Patch), ou inspecter/exporter. Expliquez d'abord l'utilisation prévue et l'étendue minimale nécessaire.
2. Obtenez l'autorisation de lecture (carte d'autorisation). Avant de lire l'historique, les fichiers de projet, le CV, les documents publics ou la mémoire du Harness, présentez la source, l'étendue, le but, le transfert externe, le lieu de stockage et la méthode de suppression conformément à references/source-consent-and-disclosure.md, et attendez une autorisation explicite. La carte d'autorisation est une interface de consentement avant la lecture, régie par cette référence ; elle est différente de la commande register-source – register-source est une entrée d'enregistrement de source à long terme après la lecture et avec l'approbation de l'utilisateur. Enregistrez également l'étendue réelle d'utilisation pour la session en cours et les documents fournis activement par l'utilisateur.
3. Collectez les preuves selon les besoins. Utilisez d'abord les réponses actuelles et les documents fournis activement par l'utilisateur. Pour les lacunes connues, lisez uniquement l'historique nécessaire ; n'importez pas des lots entiers. Le contenu provenant de la mémoire du Harness ne forme que des preuves candidates, qui doivent être marquées comme « à calibrer » ; elles ne peuvent pas devenir directement des Claim confirmées.
4. Entretien et Calibration. Conformément à references/interview-and-calibration.md, contrôlez le budget. Commencez par des expériences, choix et comportements spécifiques, puis présentez progressivement une Carte de Calibration (Calibration Card) permettant à l'utilisateur de confirmer, réécrire, rejeter ou laisser en suspens.
5. Formez des candidats Claim plats. Le Store n'a qu'un seul tableau claims[] ; les domains[] sont des étiquettes, pas une hiérarchie physique. Les nouvelles connaissances sont par défaut des candidats de Domaine avec user_status: unreviewed. Elles ne sont pas promues au niveau Core après une seule session. Le Core Summary ne peut être dérivé que des Claim confirmées, toujours valides et soutenues à travers plusieurs contextes ; il n'est pas stocké séparément.
6. Générez une Vue gelée. Compilez la Vue en fonction de l'utilisation, du sujet/exécutant/public précis et des Claim minimales nécessaires. Gèlez l'objet complet, la source_revision, la date de création, le TTL et les autorisations ensemble. Les changements ultérieurs dans le Store ne modifient pas silencieusement la Vue existante.
7. Ne stockez que les Patchs en attente. Les nouvelles connaissances issues d'une tâche ne génèrent qu'un Patch pending ; les stratégies et le langage spécifique à la tâche sont placés dans task_strategies_not_for_merge. Conformément à references/context-view-and-patch.md, examinez chaque élément ; ce n'est qu'après l'approbation explicite par l'utilisateur d'un patch_id et d'une Proposition spécifiques que le runtime peut appliquer.

Règles Minimales pour les Preuves et Connaissances

• Enregistrez séparément fact, self_report, observation, inference ; ne transformez pas une inférence en fait.
• Conservez la source de la preuve, la contre-preuve, le domaine d'application, les changements, les contradictions (Tension) et les inconnus (Unknown) ; une absence d'enregistrement ne signifie pas que cela n'a pas eu lieu.
• Tension et Unknown restent des entités de premier niveau du Store canonique actuel et peuvent également entrer dans une Vue en tant qu'objet gelé complet ; elles ne sont pas limitées à la session en cours. Le schéma/runtime actuel des Patch ne supporte que les propositions add, update, challenge, retire pour les Claim ; il n'y a pas de point d'entrée pour l'ajout ou la mise à jour de Tension/Unknown. Les nouvelles découvertes de session ne peuvent être livrées que comme « candidats non persistés » en attendant un futur accord explicite ; elles ne doivent pas être écrites silencieusement dans le Store, déguisées en Claim, insérées dans task_strategies_not_for_merge, ou présentées comme ayant été enregistrées à long terme. Les Tension/Unknown existantes dans le Store (héritées) restent lisibles et peuvent être incluses dans une Vue selon les besoins ; un futur point d'écriture nécessitera un schéma/runtime/approbation supplémentaire, non mis en œuvre dans cette session.
• N'utilisez pas le MBTI, le DISC ou une seule réponse comme preuve ; n'écrivez pas la progression d'une tâche unique, les mots-clés d'une fiche de poste, les stratégies temporaires ou les préférences d'opération d'un agent comme Claim à long terme.
• Les nouvelles connaissances entrent d'abord dans un Domaine candidat ; le Core n'est qu'une qualification de résumé dérivé et ne peut pas être promu directement après une seule tâche. Tout retour à long terme passe toujours par une révision de l'utilisateur.
• sensitivity décrit le niveau de sensibilité du contenu ; disclosure décrit le public, le but et les autorisations de persistance en aval. Ils ne sont pas interchangeables. Par défaut, excluez private et restricted.
• subject est fixé à person. team-agent ou tout autre exécutant/public non autorisé explicitement est refusé par défaut ; ne déduisez pas une autorisation personnelle du simple fait d'être dans un « même espace de travail ».

Commandes Runtime

Le runtime enregistre 17 noms d'opération : 14 opérations formelles V0.4 sont routées selon les cinq groupes ci-dessous ; 2 commandes de migration ne sont utilisées que dans les scénarios de migration ; list est un alias de compatibilité pour list-patches, pas une capacité indépendante. Les paramètres suivent toujours l'aide (--help) ; ce point d'entrée ne présume pas de flags non vérifiés. N'utilisez pas ces commandes pour la migration ou le dogfooding du vrai Store, sauf autorisation explicite. Voir references/store-operations.md pour les paramètres détaillés et les effets secondaires.

Cycle de vie du 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 crée un nouveau Store ; validate effectue une validation complète sans réparation silencieuse ; inspect affiche la révision, les compteurs et les Patches en attente ; derive-core-summary ne dérive qu'un résumé non canonique à partir des Claim confirmées et éligibles.

Enregistrement de Source

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

register-source est le seul point d'entrée pour écrire une source de preuve, consent doit être explicit. Ce n'est pas une interface d'autorisation de lecture : la carte d'autorisation avant la lecture est régie par references/source-consent-and-disclosure.md ; n'exécutez cette commande qu'après que l'utilisateur a autorisé la lecture et approuvé l'enregistrement à long terme.

Vue

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

create-view compile une Vue gelée ; la portée de sensibilité et les restrictions sont décidées à cette étape via la divulgation (disclosure) et l'approbation de l'utilisateur. validate-view ne fait que valider (péremption, usage, niveau de sensibilité, structure d'autorisation) ; il ne modifie ni ne crée de restrictions. La Vue n'est pas rafraîchie après la création.

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 écrit seulement en attente (pending) ; apply-patch nécessite à la fois une révision spécifique du Patch, --approve et la confirmation de l'acteur (actor) ; reject-patch ne modifie pas le Contexte Canonique.

Exportation et Suppression

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

export exporte par défaut uniquement public. purge est un oubli irréversible : faites d'abord un purge-plan pour prévisualiser (obtenez --plan-token), puis exécutez avec --confirmed-by et --approve ; si le Store change après la prévisualisation, le token est invalidé. Ce point d'entrée ne fournit pas d'exemples d'exécution contournant ces contraintes ; voir references/store-operations.md pour les limites complètes.

Routage de migration héritée (lecture uniquement pour scénarios de migration)

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

Ces deux commandes ne servent que les migrations historiques V0.2→V0.3 et V0.3→1.0.1 ; elles ne font pas partie des capacités de tâche régulières. Lisez d'abord references/migration-v0.3-to-v1.0.1.md, et utilisez-les conformément à ses limites de prévisualisation, de vérification, de sauvegarde et de restauration. migrate-v02 modifie le chemin passé ; ne l'exécutez que sur une copie explicite créée par l'utilisateur. La migration V0.3→1.0.1 n'autorise que la prévisualisation en lecture seule.

C File Adapter : Reçoit uniquement une Vue gelée

Le scripts/adapters/codex_file_adapter.py du paquet C est un adaptateur de fichier unidirectionnel. Il lit uniquement un fichier JSON de Vue gelée déjà généré, vérifie l'Enveloppe, le TTL, le sujet, l'usage, le allowed_use, et si chaque Claim incluse autorise à la fois le principal.id et chaque destinataire dans audience[] ; en cas d'échec, il se ferme en échec (fail-closed) sans afficher le contenu personnel rejeté. Il ne lit pas le Personal Context Store, Codex Memory, rollout ou des ressources réseau, et n'écrit pas dans le Store, la mémoire du Harness ni aucun contexte à long terme ; la sortie optionnelle ne peut pas non plus écraser la Vue d'entrée.

Les commandes conceptuelles suivantes ont été vérifiées par rapport à l'aide réelle (--help) de C. --expected-audience est une liaison de sous-ensemble répétable fournie par l'appelant : chaque type:id attendu doit exister dans le view.audience gelé, mais l'appelant n'a pas besoin d'énumérer l'ensemble du public ; ce n'est donc pas une assertion d'égalité/exhaustivité du public. Cette liaison d'appelant ne modifie pas l'invariant de sécurité : que le paramètre soit passé ou non, l'adaptateur doit toujours vérifier, pour chaque Claim incluse, que la divulgation (disclosure) couvre à la fois principal.id, tous les ID de destinataires du public dans l'Enveloppe de la Vue, et vérifier le but ; le paramètre de sous-ensemble ne peut pas assouplir la divulgation. --purpose-approved indique uniquement que le but spécifique de cette utilisation a été explicitement approuvé :

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 sortie de l'adaptateur est le résultat adapté en Markdown/JSON pour la tâche en cours ; ce n'est pas un nouveau Store, une mémoire ou un justificatif d'écriture. La tâche terminée ne génère qu'un Patch en attente. La sortie Markdown compacte conserve pour chaque Claim le user_status, la confidence, le status, le scope applicable, les evidence_refs, les counterevidence_refs et les champs de temps clés non vides ; elle n'affiche que l'ID de la source, sans développer le texte original de la preuve, les notes ou la source brute. Les Claim non vérifiées sont clairement affichées comme review=unreviewed / review=unresolved, et ne sont pas compressées en faits définitifs inconditionnels. Le Store et l'Adaptateur partagent le noyau de validation des Vues sans Store de scripts/view_validation.py ; chacun ajoute ensuite la référence de la source du Store ou la vérification de liaison de l'appelant.

Routage des Références

Le paquet officiel ne conserve que les 7 références suivantes, chacune accessible depuis ce point d'entrée ; le moment de la lecture est indiqué :

• references/interview-and-calibration.md : Lire avant le début de l'entretien. Contrat de session, budget à trois niveaux, Carte des Questions, Carte de Calibration, arrêt pour fatigue et classification des Claim.
• references/source-consent-and-disclosure.md : Lire avant toute lecture d'historique/projet/CV/Mémoire du Harness. Source unique actuelle des faits de consentement et de divulgation : carte d'autorisation, preuve candidate, sensibilité, divulgation, isolation personne/équipe et limites des décisions à fort impact. La carte d'autorisation fait partie de ceci, pas de register-source.
• references/context-view-and-patch.md : Lire lors de la compilation d'une Vue ou de la révision d'un Patch. Enveloppe de Contexte, objet gelé complet, TTL, correspondance de divulgation, mise en attente et approbation du Patch.
• references/harness-boundaries.md : Lire lorsque les limites de la Mémoire du Harness ou le File Adapter sont impliqués. Limites de la Mémoire du Harness, du Contexte Personnel et du Contexte de Tâche, ainsi que les règles de liaison de l'adaptateur de fichier concernant l'enveloppe/divulgation et le expected-audience.
• references/personal-context-model.md : Lire lorsque la sémantique de la structure du Store doit être confirmée. Entités de premier plan du Personal Context Store, modèle de preuve, limites du flux de retour des Vues/Patches et sémantique de version.
• references/store-operations.md : Lire avant d'exécuter toute commande runtime. Paramètres, effets secondaires, restrictions du système de fichiers, limites de purge et méthodes de restauration pour les 14 opérations 1.0.1 et les 2 commandes de migration.
• references/migration-v0.3-to-v1.0.1.md : Lire uniquement dans les scénarios de migration historique V0.3→1.0.1. Routes de migration en lecture seule, prévisualisation uniquement des métadonnées et sans chaîne (no-chain) ; l'ancien 0.4 n'est conservé que comme identifiant d'entrée historique et d'artefact existant.

Routage des Actifs

Trois modèles 1.0.1 associés à leurs schémas homonymes sont lus lors de la construction ou de la validation des objets correspondants :

• assets/templates/personal-context-store-v1.0.1.json : Base structurelle du Store, associée à assets/schemas/personal-context-store-v1.0.1.schema.json ; à consulter pour la construction manuelle ou la validation du Store après init.
• assets/templates/context-view-v1.0.1.json : Base structurelle de la Vue gelée, associée à assets/schemas/context-view-v1.0.1.schema.json ; à consulter lors de la compilation ou de la validation d'une Vue.
• assets/templates/context-patch-v1.0.1.json : Base structurelle du Patch, associée à assets/schemas/context-patch-v1.0.1.schema.json ; à consulter lors de la mise en attente ou de la révision d'un Patch.

Les modèles historiques V0.3 et les anciennes références ont été déplacés hors du paquet officiel et sont conservés dans archive/1.0.1-moved-out/ du projet. Les anciens artefacts 0.4 ne sont conservés que dans releases/ et ne font pas partie du protocole actuel ; ils ne doivent pas être remis dans le ZIP de publication.

Livraison et Message de Fin

En fonction de l'opération, livrez un Human Brief, les Claim candidates, les Tensions/Inconnus, une Vue gelée ou un Patch en attente. Listez également l'étendue des sources, les éléments non couverts, les limites de sensibilité et les questions à vérifier pour la prochaine fois. Concluez clairement : il s'agit d'un portrait de travail basé sur les éléments autorisés actuels ; l'utilisateur peut corriger, limiter l'utilisation, refuser ou supprimer n'importe quel élément.