---
type: RFI
asset_id: RFI-XX-WORX-GobernanzaNoModificable-v01
version: v01
status: Asignado
owner: Victor Heredia
sherpa_owner: Jay
asignado_a: Alex
fecha_creacion: 2026-06-03
fecha_limite: 2026-06-06
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-WORX-Worx
proposito: Definir e implementar la capa de archivos no-modificables dentro de la nueva estructura IntelliBanks — los archivos de gobernanza del vault deben ser de solo lectura para colaboradores.
---

# RFI — Gobernanza No-Modificable en IntelliBanks

- **Asset ID:** RFI-EL-WORX-GobernanzaNoModificable-v01
- **Fecha:** 2026-06-03
- **Owner:** Victor Heredia
- **Asignado a:** Alex
- **Fecha límite:** 2026-06-06
- **Estado:** Asignado

---

## Objetivo

Definir qué archivos de gobernanza del vault deben ser no-modificables y proponer el mecanismo técnico para implementarlo en la nueva estructura `/intellibanks` — de modo que los colaboradores puedan leerlos y usarlos, pero no editarlos accidentalmente.

---

## Contexto

EmpowerLabs está migrando el vault Reinventaverse a una nueva estructura `/intellibanks/`. Dentro de esa estructura existe un conjunto de archivos de gobernanza (convenciones, protocolos, SOPs, taxonomías) que son la "constitución" del sistema. Estos archivos deben comportarse como los documentos de solo lectura en Google Drive: cualquiera puede verlos y copiarlos, pero no modificarlos sin aprobación del owner.

El objetivo es que cuando un colaborador o cliente abra el vault, los archivos de gobernanza estén claramente marcados y protegidos — para evitar que se corrompan o modifiquen por error durante el uso cotidiano.

La analogía que usa Victor: similar a los archivos de Google Drive con permisos "solo lectura".

---

## Especificación

1. **Identificar el conjunto de archivos a proteger** — los candidatos principales son:
   - `CP-XX-IntelliBanks-Registry-v01.md` — el registro maestro
   - `MePB-XX-Taxonomia-IntelliBanks-v02.md` — taxonomía de IBs
   - `PROT-EL-WORX-Cohort-OperatingProtocols-v01.md` — protocolos del cohort
   - `SOP-EL-WORX-RoomActivation-v01.md`, `SOP-EL-WORX-BrainOSFirst-v01.md`, `SOP-EL-WORX-DocBySherpa-v01.md` — los 3 SOPs forzosos
   - Archivos de la futura capa de gobernanza en `/intellibanks/`

2. **Proponer el mecanismo técnico** para protección — opciones a evaluar:
   - Permisos de archivo a nivel del sistema operativo (`chmod 444`)
   - Convención visual en el nombre (p. ej. prefijo `GOV-` o sufijo `.readonly`)
   - Plugin de Obsidian para protección de archivos
   - Carpeta separada con permisos especiales (`_governance/` o `_core/`)
   - Combinación de lo anterior

3. **Definir el flujo de actualización permitido** — ¿quién puede modificar estos archivos? ¿Con qué proceso? (P. ej.: solo Victor con aprobación explícita, versionado obligatorio antes de modificar)

4. **Considerar la experiencia del colaborador** — ¿cómo sabe un colaborador nuevo que un archivo es de gobernanza y no debe modificarlo? Proponer señal visual o convención clara.

5. **Considerar compatibilidad con clientes** — cuando el vault se instale en un cliente, el mismo mecanismo debe funcionar en su entorno (Mac, posiblemente Windows).

---

## Entregable esperado

- **Tipo de activo:** DC (documento de decisión + especificación técnica)
- **Nombre sugerido:** `DC-EL-WORX-GobernanzaNoModificable-Spec-v01.md`
- **Ubicación en vault:** `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/`
- **Contenido mínimo del entregable:**
  - Lista definitiva de archivos a proteger
  - Mecanismo técnico recomendado con justificación
  - Flujo de modificación permitida
  - Convención visual para colaboradores
  - Estimación de esfuerzo de implementación

---

## Links relevantes

| Documento | Para qué leerlo |
|---|---|
| [[DC-XX-PreMigracion-IntelliBanks-Readiness-v01]] | Estado actual del vault y estructura de la migración a `/intellibanks/` |
| [[MePB-XX-Taxonomia-IntelliBanks-v02]] | Qué vive en cada IB — ayuda a identificar los archivos de gobernanza |
| [[PROT-EL-WORX-Cohort-OperatingProtocols-v01]] | Los 9 principios + SOPs — ejemplo de archivo de gobernanza crítico |
| [[CP-XX-IntelliBanks-Registry-v01]] | El registry maestro — candidato principal a proteger |
| [[DC-XX-RFI-TipoActivo-Definicion-v01]] | Definición del tipo RFI — contexto de este documento |

---

## Criterios de aceptación

- [ ] Lista de archivos a proteger definida y justificada
- [ ] Al menos 2 opciones técnicas evaluadas con pros/contras
- [ ] Un mecanismo recomendado con justificación clara
- [ ] El mecanismo funciona en Mac (entorno principal del equipo)
- [ ] El mecanismo es replicable cuando se instala en un vault de cliente
- [ ] Convención visual o convención de naming para identificar archivos de gobernanza
- [ ] Estimación de esfuerzo: ¿cuánto tarda implementar esto?

---

## Preguntas abiertas

- ¿El vault de clientes correrá en Mac exclusivamente, o también en Windows/Linux?
- ¿Obsidian tiene un plugin nativo o de terceros para marcar archivos como read-only?
- ¿Se prefiere una solución a nivel de OS (permisos) o a nivel de herramienta (Obsidian)?
- ¿Los archivos de gobernanza deben vivir en una carpeta separada `_governance/` o distribuidos en sus IBs correspondientes?

---

## Notas del implementador

> *(Alex completa esta sección durante la ejecución)*

---

*RFI generado por Jay · 2026-06-03 · Tipo canónico: [[DC-XX-RFI-TipoActivo-Definicion-v01]] · Plantilla: [[MiPg-XX-RFI-Plantilla-v01]]*