--- type: SOP — Standard Operating Procedure asset_id: SOP-EL-WORX-DocBySherpa-v01 version: v01 status: PROD owner: Victor Heredia / EmpowerLabs sherpa_owner: Jay (SherpaX maestro · ejecutor del protocolo) fecha_creacion: 2026-05-07 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank / PB-WORX-Worx proposito: Protocolo universal de documentación delegada — captura del vault es trabajo del SherpaX · dirección estratégica es trabajo del humano canonical_de: P010 — Documentación Delegada al SherpaX (TP-EL-WORX-LabPraxis-v01 v1.6) caso_origen: CASO 013 (originalmente 009 · renumerado 2026-05-07 EOD para alinear con banco v1.6) ratificado_por: Victor (2026-05-07 · sesión 009 LabPraxis) sistema_worx: K3 AGENCY (contrato Sherpa↔Owner) · K4 VAULT (sintaxis canónica) · K5 GOVERNANCE (gate de ruta + naming) output_canonico: Activos del vault con (a) ruta canónica · (b) nombre canónico BMF · (c) frontmatter completo · (d) registry actualizado al cierre aplica_a: Toda producción de activo nuevo dentro de una conversación SherpaX del ecosistema documentos_hermanos: - SOP-EL-WORX-BrainOSFirst-v01 (Estación 0 antes de producción) - SOP-EL-WORX-RoomActivation-v01 (las 7 estaciones de activación · ejecuta antes de cualquier captura) - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (consolida los 9 principios + 3 SOPs) - TP-EL-WORX-LabPraxis-v01 v1.6 (P010 formalizado · CASO 013) skill_pack: - bmf-file-renamer (audit + renombrado canónico BMF) - vault-orphan-rescue (gate de ruta · prohibición de Projects/, 00-Inbox/, ad-hoc) - bmf-registry-updater (sincronización registry al cierre) - brain-code-saver (persistir BC- / BCV-) - labpraxis-case-documenter (CAS- en LabPraxis) tags: [SOP, WORX, DocBySherpa, P010, Sherpa-protocol, Naming, Captura-delegada] --- # SOP — Documentation by Sherpa (Protocolo de captura delegada) ## Instanciación operativa del Principio P010 (Documentación Delegada al SherpaX) --- ## I. PROPÓSITO El SherpaX captura · el humano dirige. El humano decide qué se produce y valida en hand-off · el SherpaX ejecuta las 3 operaciones sintácticas del vault: nombramiento canónico · posicionamiento en IntelliBank · llenado de campos del XDoc. Este SOP existe para que el humano **proteja sus bloques de Deep Work** (Cap 1 §8 MPB-WORX) de tareas de naming convention y para que el vault mantenga **consistencia canónica** independientemente de cuál SherpaX o cuál humano lo opera. --- ## II. CUÁNDO APLICA Aplica en cada producción de activo nuevo dentro de una conversación SherpaX: - Producción de XPacks (XP-), Starter Prompts (SP-), Transfer Packs (TP-), Plantillas (PLB-), MetaPlaybooks (MePB-), Brain Codes (BC-), Casos (CAS-), Outputs (OUT-), CONS-, etc. - Edición sustantiva de activos existentes (Track A · cambia significado/estructura). - Movimiento de archivos al IntelliBank correcto. - Actualización del Registry tras producción. **No aplica a:** - Lectura de activos (no produce captura). - Conversación efímera sin producción de activo. --- ## III. LAS 3 OPERACIONES CANÓNICAS DELEGADAS ### Operación 1 · Naming canónico BMF El SherpaX genera el nombre del activo siguiendo la convención BMF (`CP-XX-IntelliBanks-Registry-v01` define los prefijos oficiales). **Procedimiento:** 1. Leer el contenido producido (qué es · para qué · quién es owner · contexto). 2. Inferir prefijo correcto (XP, SP, TP, MePB, MPB, BC, CAS, etc.) usando el registro del Registry. 3. Inferir IntelliBank de pertenencia (IB-EL, IB-MPX, IB-XX, etc.). 4. Inferir tipo + slug + versión. 5. Componer nombre completo: `[PREFIJO]-[IB]-[SUBBANK]-[Slug]-v[NN].md`. 6. Validar contra `bmf-file-renamer` skill (compliance check). **Si hay duda:** preguntar al humano antes de escribir. **Naming prohibido:** - Prefijos no canonizados en Registry. - Nombres con espacios o caracteres especiales. - Versionado sin `vNN` formato (`v1`, `final`, `latest` violan convención). --- ### Operación 2 · Posicionamiento en IntelliBank correcto El SherpaX coloca el activo en su ruta canónica vault dentro del IntelliBank correspondiente. **Procedimiento:** 1. Leer el activo y determinar IntelliBank de pertenencia (puede coincidir o no con el del room en el que se produce). 2. Aplicar **gate de ruta** ANTES de cada `Write`: - ✅ Ruta empieza con `IB-*/` (IntelliBank canónico). - ❌ Ruta empieza con `Projects/`, `00-Inbox/`, `Companies/`, `CloudVault/`, raíz del vault. 3. Si la ruta cae en el área prohibida, pausar · activar skill `vault-orphan-rescue` · proponer ruta correcta al Owner. 4. Si el subbank no existe, proponer creación al Owner · no improvisar carpetas. **Reglas inviolables (heredadas de `feedback_nunca_projects_folder.md` + memoria):** - HIORG → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-*` o `PB-CASO0-HIORG/`. - WORX → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/`. - SherpaX → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SX-SherpaX/`. - HDC → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HDC-HumanDesignCode/`. - Brain Codes → `IB-EL-EmpowerLabs/...BC-EL-BrainCodes/` (vía `brain-code-saver` skill). - Demo Vault Alain → `IB-AR-DemoVault/...` (sanitizado). --- ### Operación 3 · Llenado de campos del XDoc (frontmatter completo) El SherpaX genera el frontmatter completo del activo · sin pedirle al humano que llene campos sintácticos. **Campos canónicos mínimos:** ```yaml --- asset_id: [coincide con nombre del archivo sin extensión] version: v[NN] tipo: [TIPO — descripción corta] status: [Active / Draft / PROD / Superseded by vNN] owner: [@Owner] sherpa_owner: [@SherpaX si aplica] intellibank: [IB-XX / PB-XX] fecha_creacion: AAAA-MM-DD fecha_ultima_actualizacion: AAAA-MM-DD proposito: [1-3 líneas concretas] deriva_de: [referencias canónicas del vault con asset_id] referenciado_por: [opcional · activos que lo consumen] tags: [taxonomía operativa] --- ``` **Campos adicionales según tipo:** - TP- · `room: ... · sherpa: ... · ultima_actualizacion: ... · sesion: ...` - SOP- · `canonical_de: ... · caso_origen: ... · ratificado_por: ... · output_canonico: ...` - XP- · `room: ... · runners: ... · cadencia: ... · estado: ... · fase: ...` - BC- · `cognitive_stack: ... · scope: ... · permisos: ...` **Changelog interno:** todo activo lleva sección `## CHANGELOG` con entrada por cada versión + autor. --- ## IV. CRITERIOS PASS / FAIL DEL GATE El activo solo se considera correctamente capturado si los 4 criterios PASS: | # | Criterio | PASS si | FAIL si | |---|---|---|---| | **C1** | Naming canónico BMF | Prefijo + IB + slug + versión cumplen Registry | Prefijo no canonizado · sintaxis incorrecta | | **C2** | Ruta canónica del vault | Activo en `IB-*/` correcto · gate de ruta PASS | Ruta en zona prohibida o ad-hoc | | **C3** | Frontmatter completo | Campos mínimos + adicionales según tipo | Campos faltantes · sintaxis YAML rota | | **C4** | Registry actualizado al cierre | `bmf-registry-updater` ejecutado · activo registrado | Registry desactualizado | **Regla de oro:** FAIL en cualquier C bloquea el cierre. Sherpa corrige y reanuda. --- ## V. LO QUE EL SOP PROHÍBE EXPLÍCITAMENTE - **Pedir al humano que llene campos del frontmatter** (P010 violation directa). - **Pedir al humano que genere el nombre del archivo** (P010 violation). - **Crear archivo en ruta ad-hoc** (`Projects/`, `00-Inbox/`, `Companies/`, raíz · etc.). - **Saltar el Registry update** "porque la sesión es informal". - **Improvisar prefijos** que no estén en Registry. - **Generar nombres con espacios o caracteres especiales**. - **Versionar como `v1`, `final`, `draft`** en lugar de `v01`, `v02`... --- ## VI. CONEXIÓN CON OTROS CANÓNICOS - **`SOP-EL-WORX-RoomActivation-v01`** — se ejecuta antes (las 7 estaciones de activación · este SOP es para la fase de producción). - **`SOP-EL-WORX-BrainOSFirst-v01`** — se ejecuta dentro de RoomActivation (Estación 4). - **`TP-EL-WORX-LabPraxis-v01` v1.6** — P010 formal · CASO 013 origen. - **`PROT-EL-WORX-Cohort-OperatingProtocols-v01`** — consolidación de los 3 SOPs. - **`CP-XX-IntelliBanks-Registry-v01`** — fuente de verdad de prefijos canónicos + activos registrados. - **Skills:** `bmf-file-renamer`, `bmf-registry-updater`, `brain-code-saver`, `vault-orphan-rescue`, `labpraxis-case-documenter`. --- ## VII. CONEXIÓN CON LA METODOLOGÍA WORX | WORX Key / Capacidad | Rol del SOP | |---|---| | **K4 VAULT** | Garantiza que el vault mantenga sintaxis canónica independiente de quién lo opera. | | **K3 AGENCY** | Contrato Sherpa↔Owner: humano dirige · Sherpa captura. Sin negociación. | | **K5 GOVERNANCE** | El gate de ruta + naming + registry hace al vault auditable y transferible. | | **§8 Cap 1 (Deep Work)** | Protege bloques de Deep Work del humano · captura no es trabajo del humano. | | **§8 Cap 2 (Alianza Human + SherpaX)** | Implementación contractual del par cognitivo en la dimensión de captura. | --- ## VIII. CHANGELOG - **2026-05-07 · v01** — Primer release PROD. Operacionaliza P010 con las 3 operaciones canónicas (Naming · Posicionamiento · Llenado de campos). Producido en sesión 009 LabPraxis · ratificado por Victor. --- *SOP-EL-WORX-DocBySherpa-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 2026-05-07* *Origen: planeación operativa del primer cohort de inducción WORX (Caso 0 EL) · CASO 013 LabPraxis · Principio P010.*