rootkid0-initializer 0.1.0

package/06-deployment/AGENTS.md

@@ -0,0 +1,31 @@
+# AGENTS
+
+Entrypoint local para trabajo en `06-deployment`.
+
+## Scope
+
+Configurar entornos, CI/CD y monitoreo operativo.
+
+## Reglas locales
+
+- Favorecer configuraciones repetibles y seguras.
+- Evitar cambios manuales no documentados.
+- No considerar cierre operativo sin cumplir el gate de Deployment.
+
+## Deployment Configuration
+
+- Estandar operativo: `06-deployment/DEPLOYMENT-OPERATING-MODEL.md`
+- Entregables obligatorios:
+  - `01-environments.md`
+  - `02-ci-cd.md`
+  - `03-config.md`
+  - `04-monitoring.md`
+- Criterio de paso: release estable, observable y gate aprobado.
+
+## Orden de carga recomendado
+
+1. Contexto global: `.opencode/context.md`
+2. AGENTS local: `06-deployment/AGENTS.md`
+3. Skill global: `.opencode/skills/global/SKILL.md`
+4. Skill local: `06-deployment/skills/SKILL.md`
+5. Rol: `AGENTS.md` (raiz)

package/06-deployment/DEPLOYMENT-OPERATING-MODEL.md

@@ -0,0 +1,82 @@
+# Deployment Operating Model
+
+## Objective
+
+Estandarizar Deployment para liberar cambios de forma segura, repetible y observable, minimizando riesgo operativo.
+
+## Inputs
+
+- Development aprobado (Go) en `05-development/`.
+- Release candidate disponible.
+- Configuracion y ambientes listos para despliegue.
+
+## Mandatory Deliverables
+
+1. `01-environments.md`
+2. `02-ci-cd.md`
+3. `03-config.md`
+4. `04-monitoring.md`
+
+## Mandatory Content by Deliverable
+
+- `01-environments.md`: definicion de ambientes, diferencias controladas y responsables.
+- `02-ci-cd.md`: pipeline de build/test/deploy y condiciones de promotion.
+- `03-config.md`: variables, secretos, control de cambios y estrategia de rollback.
+- `04-monitoring.md`: logs, metricas, alertas y ownership operativo.
+
+## Execution Steps
+
+1. Validar paridad entre ambientes y prerequisitos de release.
+2. Ejecutar pipeline CI/CD con checks obligatorios.
+3. Aplicar cambios de configuracion con versionado.
+4. Ejecutar despliegue controlado y verificar salud inicial.
+5. Activar monitoreo y alertas para observabilidad temprana.
+6. Registrar resultado de release y acciones post-deploy.
+
+## Deployment Gate (Go / No-Go)
+
+La fase solo se considera aprobada si todas las condiciones son verdaderas:
+
+- El pipeline de despliegue completa sin errores criticos.
+- Existe plan de rollback probado o documentado y aplicable.
+- Monitoreo y alertas estan activos con ownership definido.
+- La configuracion de runtime esta validada por ambiente.
+- Hay validacion operativa inicial post-deploy.
+
+Si una condicion falla, el resultado es **No-Go** y se itera en Deployment.
+
+## Validation Checklist
+
+- [ ] `01-environments.md` refleja entornos reales y responsables.
+- [ ] `02-ci-cd.md` documenta flujo y gates del pipeline.
+- [ ] `03-config.md` define control de cambios y rollback.
+- [ ] `04-monitoring.md` incluye alertas y canales de respuesta.
+- [ ] El release candidate fue desplegado y verificado.
+- [ ] Los incidentes iniciales (si existen) tienen plan de accion.
+
+## Output Format
+
+Al cerrar Deployment, registrar decision en `01-environments.md` con este formato:
+
+```md
+## Deployment Decision
+
+- Status: Go | No-Go
+- Date: YYYY-MM-DD
+- Approved by: <nombre/rol ops>
+- Release version: <version>
+- Monitoring status: Activo | Parcial | Inactivo
+- Rollback status: Listo | No listo
+- Open incidents:
+  - <incidente 1>
+  - <incidente 2>
+- Next step:
+  - Si Go: operar y mantener en Production
+  - Si No-Go: corregir pipeline/config/observabilidad
+```
+
+## Quality Rules
+
+- No desplegar cambios sin criterio de rollback.
+- No cerrar fase sin observabilidad minima activa.
+- Cada incidente de despliegue debe quedar registrado con owner.

package/06-deployment/skills/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: local-deployment-conventions
+description: Convenciones de despliegue y operacion. Trigger: cambios en 06-deployment.
+---
+
+# Skill local 06-deployment
+
+- Mantener checklists de verificacion de despliegue.
+- Minimizar riesgo operativo en cambios de config.
+- Trabajar siempre contra el estandar `06-deployment/DEPLOYMENT-OPERATING-MODEL.md`.
+- No marcar Deployment como completo sin monitoreo activo y rollback definido.

package/07-production/01-operations-runbook.md

@@ -0,0 +1,23 @@
+# Operations Runbook
+
+## Objective
+
+Definir como operar el sistema en produccion de forma estable y repetible.
+
+## Service Ownership
+
+- Responsable operativo:
+- Equipo de soporte:
+- Horario y esquema de guardias:
+
+## Daily Operations
+
+- Revisar estado de servicios y dependencias.
+- Verificar paneles de salud y alertas criticas.
+- Confirmar jobs y procesos programados.
+
+## Standard Procedures
+
+- Reinicio controlado de servicios.
+- Escalamiento tecnico y de negocio.
+- Criterios de comunicacion interna y externa.

package/07-production/02-incident-management.md

@@ -0,0 +1,25 @@
+# Incident Management
+
+## Objective
+
+Estandarizar la deteccion, respuesta y cierre de incidentes en produccion.
+
+## Severity Model
+
+- Sev1: caida total o impacto critico.
+- Sev2: degradacion significativa.
+- Sev3: impacto acotado o workaround disponible.
+
+## Response Flow
+
+1. Detectar y confirmar incidente.
+2. Asignar owner y canal de comunicacion.
+3. Mitigar impacto inmediato.
+4. Resolver causa principal o estabilizar temporalmente.
+5. Cerrar incidente con registro completo.
+
+## Postmortem Rules
+
+- Registrar causa raiz.
+- Definir acciones preventivas con owner y fecha.
+- Compartir aprendizajes con el equipo.

package/07-production/03-performance-capacity.md

@@ -0,0 +1,24 @@
+# Performance and Capacity
+
+## Objective
+
+Monitorear capacidad y performance para anticipar degradaciones y planificar crecimiento.
+
+## Core Indicators
+
+- Latencia p50/p95/p99.
+- Error rate por servicio.
+- Throughput por flujo critico.
+- Uso de CPU, memoria y almacenamiento.
+
+## Capacity Planning
+
+- Baseline de carga actual.
+- Umbrales de alerta y saturacion.
+- Plan de escalado horizontal o vertical.
+
+## Review Cadence
+
+- Revision semanal de tendencias.
+- Revision mensual de capacidad.
+- Ajustes en backlog de mejora cuando corresponda.

package/07-production/04-continuous-improvement.md

@@ -0,0 +1,24 @@
+# Continuous Improvement
+
+## Objective
+
+Convertir hallazgos de operacion en mejoras concretas para estabilidad, calidad y velocidad de respuesta.
+
+## Improvement Sources
+
+- Incidentes y postmortems.
+- Alertas recurrentes.
+- Desviaciones de performance.
+- Feedback de usuarios y negocio.
+
+## Prioritization Criteria
+
+- Impacto en cliente o negocio.
+- Riesgo operativo reducido.
+- Esfuerzo de implementacion.
+- Dependencias tecnicas.
+
+## Tracking
+
+- Lista de mejoras con estado, owner y fecha objetivo.
+- Validacion de impacto post-implementacion.

package/07-production/AGENTS.md

@@ -0,0 +1,31 @@
+# AGENTS
+
+Entrypoint local para trabajo en `07-production`.
+
+## Scope
+
+Operar el sistema en produccion con confiabilidad, respuesta a incidentes y mejora continua.
+
+## Reglas locales
+
+- Priorizar estabilidad y recuperacion rapida.
+- Registrar incidentes, causas raiz y acciones correctivas.
+- Mantener foco en observabilidad y ownership operativo.
+
+## Production Configuration
+
+- Estandar operativo: `07-production/PRODUCTION-OPERATING-MODEL.md`
+- Entregables obligatorios:
+  - `01-operations-runbook.md`
+  - `02-incident-management.md`
+  - `03-performance-capacity.md`
+  - `04-continuous-improvement.md`
+- Criterio de fase: operacion estable, incidentes controlados y mejora continua activa.
+
+## Orden de carga recomendado
+
+1. Contexto global: `.opencode/context.md`
+2. AGENTS local: `07-production/AGENTS.md`
+3. Skill global: `.opencode/skills/global/SKILL.md`
+4. Skill local: `07-production/skills/SKILL.md`
+5. Rol: `AGENTS.md` (raiz)

package/07-production/PRODUCTION-OPERATING-MODEL.md

@@ -0,0 +1,81 @@
+# Production Operating Model
+
+## Objective
+
+Estandarizar Production para operar el sistema con confiabilidad, gestionar incidentes de forma predecible y sostener una mejora continua.
+
+## Inputs
+
+- Deployment aprobado (Go) en `06-deployment/`.
+- Monitoreo y alertas activos.
+- Ownership operativo definido.
+
+## Mandatory Deliverables
+
+1. `01-operations-runbook.md`
+2. `02-incident-management.md`
+3. `03-performance-capacity.md`
+4. `04-continuous-improvement.md`
+
+## Mandatory Content by Deliverable
+
+- `01-operations-runbook.md`: procedimientos operativos, ownership y rutina diaria.
+- `02-incident-management.md`: severidades, respuesta, escalamiento y postmortem.
+- `03-performance-capacity.md`: indicadores clave, umbrales y plan de capacidad.
+- `04-continuous-improvement.md`: backlog de mejoras y criterio de priorizacion.
+
+## Execution Steps
+
+1. Establecer operacion base y responsables.
+2. Monitorear continuamente salud, errores y capacidad.
+3. Gestionar incidentes con flujo y tiempos de respuesta definidos.
+4. Registrar causas raiz y acciones preventivas.
+5. Priorizar mejoras con impacto operativo y de negocio.
+6. Revisar periodicamente estabilidad y tendencias.
+
+## Production Gate (Healthy / At Risk)
+
+La fase se considera saludable cuando todas las condiciones son verdaderas:
+
+- Runbook operativo actualizado y en uso.
+- Flujo de incidentes activo con owner y seguimiento.
+- Indicadores de performance/capacidad monitoreados regularmente.
+- Mejoras de alto impacto priorizadas y en ejecucion.
+- Riesgos operativos criticos bajo control o con plan activo.
+
+Si una condicion falla, el estado es **At Risk** y se requiere plan de correccion.
+
+## Validation Checklist
+
+- [ ] `01-operations-runbook.md` cubre operaciones diarias y escalamiento.
+- [ ] `02-incident-management.md` tiene severidades y proceso de postmortem.
+- [ ] `03-performance-capacity.md` define umbrales y revisiones.
+- [ ] `04-continuous-improvement.md` mantiene backlog de mejoras activo.
+- [ ] Hay evidencia de seguimiento operativo periodico.
+
+## Output Format
+
+Al cerrar un ciclo operativo, registrar estado en `01-operations-runbook.md` con este formato:
+
+```md
+## Production Status
+
+- Status: Healthy | At Risk
+- Date: YYYY-MM-DD
+- Reviewed by: <nombre/rol>
+- Active incidents:
+  - <incidente 1>
+  - <incidente 2>
+- Top risks:
+  - <riesgo 1>
+  - <riesgo 2>
+- Next actions:
+  - <accion 1>
+  - <accion 2>
+```
+
+## Quality Rules
+
+- No cerrar incidentes sin causa raiz documentada.
+- No mantener alertas ruidosas sin ajuste.
+- Cada mejora operacional debe tener owner y fecha objetivo.

package/07-production/skills/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: local-production-conventions
+description: Convenciones de operacion y mejora continua. Trigger: cambios en 07-production.
+---
+
+# Skill local 07-production
+
+- Priorizar continuidad operativa y reduccion de riesgo.
+- Medir y revisar tendencias de incidentes y performance.
+- Documentar decisiones operativas y acciones de mejora.
+- Trabajar siempre contra el estandar `07-production/PRODUCTION-OPERATING-MODEL.md`.

package/99-common/01-readme-base.md

@@ -0,0 +1,16 @@
+# README Base - {{PROJECT_NAME}}
+
+## Descripcion
+
+Resumen corto del proyecto y su objetivo.
+
+## Inicio rapido
+
+1. Instalar dependencias.
+2. Levantar entorno local.
+3. Ejecutar pruebas.
+
+## Documentacion relacionada
+
+- docs/framework-guide.md
+- templates/management/02-roadmap.md

package/99-common/02-initial-checklist.md

@@ -0,0 +1,7 @@
+# Checklist Inicial - {{PROJECT_NAME}}
+
+- [ ] Configuracion local creada.
+- [ ] Alcance MVP validado.
+- [ ] Backlog inicial priorizado.
+- [ ] Responsables definidos.
+- [ ] Riesgos criticos identificados.

package/99-common/03-glossary.md

@@ -0,0 +1,7 @@
+# Glossary - {{PROJECT_NAME}}
+
+| Termino | Definicion |
+|---|---|
+| MVP | Version minima funcional para validar valor. |
+| Scope | Limites de lo que incluye el proyecto. |
+| Done | Criterio para marcar una tarea como terminada. |

package/99-common/04-release-closure-product-3-4.md

@@ -0,0 +1,47 @@
+# Release Closure - Product 3 and 4
+
+## Scope
+
+Este documento cierra formalmente:
+
+- Producto 3: Estructura local ejecutable.
+- Producto 4: CLI / bootstrap initializer.
+
+## Final Decision
+
+- Product 3 Status: DONE
+- Product 4 Status: DONE
+- Closure date: 2026-03-31
+- Closure mode: Opcion 1 (MCP recomendados con placeholders, sin bloqueo de release)
+
+## Evidence - Product 3
+
+- Estructura por fases disponible: `01-business/` a `07-production/` y `99-common/`.
+- Modelo local por subproyecto aplicado: `AGENTS.md` + `skills/SKILL.md`.
+- Sin `.opencode/` local en subproyectos.
+- OpenCode global centralizado en `.opencode/`.
+- Gates operativos definidos fase por fase (Discovery, Proposal, Design, Management, Development, Deployment, Production).
+
+## Evidence - Product 4
+
+- Bootstrap Bash operativo: `rootkid0-bootstrap/init-project.sh`.
+- Bootstrap PowerShell operativo por implementacion: `rootkid0-bootstrap/init-project.ps1`.
+- Opcion MCP recomendada (no obligatoria):
+  - Bash: `--setup-mcp`
+  - PowerShell: `-SetupMcp`
+- Placeholders de proyecto reemplazables con `{{PROJECT_NAME}}`.
+
+## Validation Summary
+
+- Bash syntax check: OK (`init-project.sh`, `helpers.sh`).
+- Smoke test Bash (creacion de proyecto desde baseline actual): OK.
+- Validacion de `pwsh` en este entorno: no disponible (`pwsh: command not found`).
+
+## Accepted Deferments (Post-Release)
+
+- MCP `context7`, `engram`, `notion` quedan como recomendados con plantilla y placeholders.
+- Configuracion final de comandos/args/env especificos se define por entorno de equipo.
+
+## Immediate Next Step
+
+- Publicar este estado en repositorio Git como cierre de Producto 3 y 4.

package/99-common/05-p1-notion-multi-db-plan.md

@@ -0,0 +1,126 @@
+# P1 Plan - Notion management template (multi-DB)
+
+## Objetivo
+
+Definir un template de gestion en Notion, basado en multiples bases relacionadas, para operar el framework por fases `01..07` con trazabilidad de gates, entregables y trabajo operativo.
+
+Este artefacto cubre solo planeacion y diseno funcional del template. No incluye aprovisionamiento por API en esta iteracion.
+
+## Scope
+
+- Disenar arquitectura multi-DB para gestion de proyectos.
+- Definir modelo de relaciones entre `Projects`, `Phases`, `Deliverables`, `Backlog`, `Risks`, `Decisions` e `Incidents`.
+- Establecer vistas minimas para operar el ciclo semanal y los gates.
+- Definir ritual operativo para mantener el sistema vivo y util.
+- Alinear nombres y flujo con el modelo por fases del repositorio y filosofia de gate `Go/No-Go`.
+
+## Out of Scope
+
+- Integracion con Notion API, scripts o IaC.
+- Automatizaciones avanzadas (recordatorios, webhooks, sync con Jira, etc.).
+- Dashboards ejecutivos de BI fuera de Notion.
+- Ajustes de proceso fuera del framework actual `01..07`.
+
+## Arquitectura multi-DB (opcion 1)
+
+Se adopta un modelo de 7 bases separadas y relacionadas, en lugar de una base unica, para mantener responsabilidades claras y consultas operativas simples:
+
+1. `Projects` (nivel programa/proyecto)
+2. `Phases` (control del flujo `01..07` y gate)
+3. `Deliverables` (evidencia y cierre por fase)
+4. `Backlog` (ejecucion de trabajo)
+5. `Risks` (riesgo vivo con mitigacion)
+6. `Decisions` (trazabilidad de decisiones)
+7. `Incidents` (incidentes y aprendizaje operativo)
+
+Decision de arquitectura MVP:
+
+- Relacionar todo contra `Projects` para trazabilidad transversal.
+- Usar `Phases` como columna vertebral del ciclo `01..07`.
+- Conectar `Deliverables` y `Backlog` para reflejar plan vs evidencia.
+- Conectar `Risks`, `Decisions` e `Incidents` para cerrar el loop de gobierno.
+
+## Modelo de relaciones
+
+Relaciones principales (cardinalidad esperada):
+
+- `Projects` 1 -> N `Phases`
+- `Projects` 1 -> N `Deliverables`
+- `Projects` 1 -> N `Backlog`
+- `Projects` 1 -> N `Risks`
+- `Projects` 1 -> N `Decisions`
+- `Projects` 1 -> N `Incidents`
+- `Phases` 1 -> N `Deliverables`
+- `Phases` 1 -> N `Backlog`
+- `Phases` 1 -> N `Risks`
+- `Phases` 1 -> N `Decisions`
+- `Phases` 1 -> N `Incidents`
+- `Backlog` N -> 1 `Deliverables` (item que produce o actualiza evidencia)
+- `Backlog` N -> 1 `Risks` (item de mitigacion)
+- `Decisions` N -> 1 `Risks` (decision que responde a un riesgo)
+- `Incidents` N -> 1 `Decisions` (decision tomada por incidente)
+- `Incidents` N -> 1 `Backlog` (accion correctiva/preventiva)
+
+## Vistas requeridas (MVP)
+
+### Projects
+
+- `Proyectos - Dashboard`: tabla con estado global, salud y gate actual.
+- `Proyectos - En riesgo`: filtro por salud `Amarillo/Rojo`.
+
+### Phases
+
+- `Fases - Board de gate`: columnas por estado (`Not started`, `In progress`, `Ready for gate`, `Go`, `No-Go`).
+- `Fases - Timeline`: fechas plan vs fecha de gate.
+
+### Deliverables
+
+- `Entregables - Pendientes de aprobacion`: estado != `Approved` y `obligatorio = true`.
+- `Entregables - Por fase`: agrupado por `codigo_fase`.
+
+### Backlog
+
+- `Backlog - Priorizado`: tabla por prioridad `P0..P3`.
+- `Backlog - Ejecucion`: board por estado.
+- `Backlog - Sin criterio de cierre`: control de calidad.
+
+### Risks
+
+- `Riesgos - Activos`: estado abierto o mitigando.
+- `Riesgos - Alto impacto`: impacto `Alto` y probabilidad `Media/Alta`.
+
+### Decisions
+
+- `Decisiones - Pendientes`: estado `Propuesta`.
+- `Decisiones - Aprobadas`: historial de decisiones vigentes.
+
+### Incidents
+
+- `Incidentes - Activos`: estado != `Cerrado`.
+- `Incidentes - Postmortem pendiente`: sin `postmortem_url` con severidad `SEV1/SEV2`.
+
+## Ritual de operacion
+
+Cadencia minima recomendada:
+
+- Diario (15 min): actualizar `Backlog`, `Incidents` y bloqueadores de `Phases`.
+- Semanal (45 min): revisar `Risks`, decisiones pendientes y estado de entregables obligatorios.
+- Cierre de fase (60 min): validar evidencia en `Deliverables`, registrar `Decision` del gate (`Go/No-Go`) y actualizar siguiente fase.
+
+Secuencia de operacion por fase:
+
+1. Abrir fase en `Phases` con owner y criterios de gate.
+2. Planificar trabajo en `Backlog` ligado a la fase.
+3. Ejecutar y adjuntar evidencia en `Deliverables`.
+4. Revisar riesgos/incidentes y registrar decisiones.
+5. Ejecutar gate `Go/No-Go` y registrar resultado.
+
+## Definition of Done (P1 planning)
+
+P1 se considera completo cuando:
+
+- Existe este plan y esta aprobado por el responsable operativo.
+- Existe especificacion de schema detallada por DB y propiedad.
+- Existe checklist manual de implementacion ejecutable en Notion.
+- Se mantienen nombres y flujo alineados con `01..07` y gates del framework.
+- La documentacion queda visible desde README raiz.