diff --git a/.straymark/02-design/decisions/ADR-2026-07-04-001-restaurar-delimitacion-crates.md b/.straymark/02-design/decisions/ADR-2026-07-04-001-restaurar-delimitacion-crates.md new file mode 100644 index 0000000..a0d824c --- /dev/null +++ b/.straymark/02-design/decisions/ADR-2026-07-04-001-restaurar-delimitacion-crates.md @@ -0,0 +1,131 @@ +--- +id: ADR-2026-07-04-001 +title: "Restaurar la delimitación de funciones por crate (conflict, audit, telemetry)" +status: draft +created: 2026-07-04 +updated: 2026-07-04 +agent: claude-code-v1.0 +confidence: high +review_required: true +risk_level: medium +eu_ai_act_risk: not_applicable +iso_42001_clause: [6, 8] +alternatives_documented: [] +api_changes: [] +tags: [architecture, crates, hexagonal, technical-debt, replanteo] +related: [CHARTER-02-road-to-functional-v0-1, AILOG-2026-07-04-001] +supersedes: [] +--- + +# ADR: Restaurar la delimitación de funciones por crate + +## Status + +draft — **decisión D1 tomada por el operador el 2026-07-04**; este ADR la +formaliza y requiere su revisión/aprobación. + +**Note**: This document was created by an AI agent and requires human review. + +## Context + +El diseño original (`lnxdrive-guide/`) prescribe funciones **delimitadas por +crate**: `lnxdrive-conflict` y `lnxdrive-audit` como crates independientes +publicables (`07-Extensibilidad/04-artefactos-reutilizables.md`, +`05-Implementacion/03`, `08-Distribucion/01`) y `lnxdrive-telemetry` como +crate/proceso separado (`04-Componentes/13-telemetria.md`). + +Durante la implementación **se ignoró ese plano**: la lógica de conflictos y +auditoría se incrustó como entidades de dominio dentro de `lnxdrive-core` +(`domain/conflict.rs`, `domain/audit.rs`) y los tres crates quedaron como stubs +de 7-8 líneas sin código ni consumidores. El catálogo de desviaciones del +replanteo (`new-guide/06-catalogo-desviaciones.md` §3) lo documenta con +evidencia. Fuerzas en juego: (a) la delimitación por crate hace las fronteras +de responsabilidad verificables y habilita la publicación futura (Fase 10); +(b) un crate vacío miente sobre la arquitectura; (c) mover código funcionando +es riesgo de regresión sin beneficio funcional inmediato; (d) los milestones +funcionales M1–M6 (CHARTER-02) son la prioridad del proyecto. + +## Decision + +**Se restaura el diseño de funciones delimitadas por crate, de forma +incremental y sin bloquear los milestones funcionales:** + +1. Los crates `lnxdrive-conflict`, `lnxdrive-audit` y `lnxdrive-telemetry` + **se conservan** en el workspace. +2. **La funcionalidad nueva nace en su crate**: la detección/resolución de + conflictos (milestone M6 de CHARTER-02) se implementa en `lnxdrive-conflict`, + consumiendo los tipos de dominio de `lnxdrive-core`. +3. **La funcionalidad existente migra como epic estructural de v0.2.0-beta** + ("restaurar delimitación de crates"): extracción de la lógica de audit de + core a `lnxdrive-audit`. La persistencia puede seguir en la SQLite compartida + vía `IStateRepository` — el crate delimita *código*, no *almacenamiento* + (coherente con el propio diseño de puertos de la guía). +4. `lnxdrive-telemetry` se implementa en v0.2.0-beta bajo la redefinición de + ADR-2026-07-04-002 (interna-only). +5. Los tipos de *dominio* (entidad `Conflict`, `AuditEntry`, transiciones de + estado) permanecen en `lnxdrive-core` — la arquitectura hexagonal no cambia; + lo que se delimita son los *servicios/motores* sobre esos tipos. + +## Alternatives Considered + +### A. Borrar los stubs y actualizar la guía hacia el código +- **Pros**: honestidad estructural inmediata; cero refactor; git conserva la historia. +- **Cons**: abandona la intención de diseño original (fronteras verificables, + publicación futura); consolida la deriva como hecho consumado. +- **Por qué no**: decisión explícita del operador — la desviación fue un + accidente de implementación, no una evolución deliberada del diseño. + +### B. Extraer todo inmediatamente (audit + conflict antes de M1) +- **Pros**: coherencia estructural total desde ya. +- **Cons**: semanas de refactor de código funcionando, con riesgo de regresión, + antes de tener un sistema que haga login. Invierte las prioridades. +- **Por qué no**: el proyecto no tiene sistema funcional; la estructura no puede + ir antes que la capacidad. + +### C. Restauración incremental (elegida) +- **Pros**: lo nuevo nace bien ubicado (costo marginal ~0); lo existente migra + cuando hay presupuesto; los milestones funcionales no se bloquean. +- **Cons**: ventana de incoherencia (audit en core hasta v0.2) — mitigada + documentándola explícitamente en la guía (plan B3/B6). + +## Consequences + +**Positivas**: M6 entrega `lnxdrive-conflict` real; las fronteras de +responsabilidad vuelven a ser las del diseño; la publicación de crates (Fase 10) +sigue siendo alcanzable; la guía y el código convergen con un plan datado. + +**Negativas**: hasta v0.2, `lnxdrive-audit`/`lnxdrive-telemetry` siguen siendo +stubs — la guía debe declarar el estado de migración (plan B3) para no mentir. + +**Neutras**: la tabla de crates canónica pasa a ser la de 12 miembros de +`08-Distribucion/01`; `lnxdrive-ratelimit`/`lnxdrive-state` quedan como +candidatos de extracción de Fase 10, no deuda actual. + +## Affected Components + +| Componente | Impacto | +|---|---| +| `lnxdrive-engine/crates/lnxdrive-conflict/` | Deja de ser stub en M6 (CHARTER-02) | +| `lnxdrive-engine/crates/lnxdrive-audit/` | Recibe la lógica de `core/domain/audit.rs` en v0.2 | +| `lnxdrive-engine/crates/lnxdrive-telemetry/` | Se implementa en v0.2 según ADR-2026-07-04-002 | +| `lnxdrive-engine/crates/lnxdrive-core/` | Conserva tipos de dominio; cede servicios/motores | +| `lnxdrive-guide/` (docs B3/B6 del plan) | Documenta lista canónica + estado de migración | + +## Implementation Plan + +1. CHARTER-02 M6: detección de conflictos nace en `lnxdrive-conflict` (2026, v0.1). +2. v0.2.0-beta, epic estructural: extracción de audit; implementación de telemetry. +3. Guía actualizada según `new-guide/08-plan-actualizacion-guia.md` B3/B6. + +## Success Metrics + +- M6 cerrado con `lnxdrive-conflict` como dependencia real de `lnxdrive-sync` + (ya no stub sin consumidores). +- Al cierre de v0.2: `grep -c "pub" crates/lnxdrive-audit/src/lib.rs` > 0 y + `core/domain/audit.rs` reducido a tipos de dominio. +- `straymark analyze --contracts` (declared-vs-wired) sin hallazgos sobre los + tres crates al cierre de v0.2. + +--- + + diff --git a/.straymark/02-design/decisions/ADR-2026-07-04-002-telemetria-interna-only.md b/.straymark/02-design/decisions/ADR-2026-07-04-002-telemetria-interna-only.md new file mode 100644 index 0000000..392cb9b --- /dev/null +++ b/.straymark/02-design/decisions/ADR-2026-07-04-002-telemetria-interna-only.md @@ -0,0 +1,136 @@ +--- +id: ADR-2026-07-04-002 +title: "Telemetría interna-only: se descarta todo export externo de datos" +status: draft +created: 2026-07-04 +updated: 2026-07-04 +agent: claude-code-v1.0 +confidence: high +review_required: true +risk_level: medium +eu_ai_act_risk: not_applicable +iso_42001_clause: [6, 8] +alternatives_documented: [] +api_changes: [] +tags: [telemetry, privacy, observability, product-promise, replanteo] +related: [ADR-2026-07-04-001, CHARTER-02-road-to-functional-v0-1, AILOG-2026-07-04-001] +supersedes: [] +--- + +# ADR: Telemetría interna-only — se descarta todo export externo de datos + +## Status + +draft — **decisión D3 tomada por el operador el 2026-07-04**; este ADR la +formaliza y requiere su revisión/aprobación. + +**Note**: This document was created by an AI agent and requires human review. + +## Context + +El diseño original de telemetría (`lnxdrive-guide/04-Componentes/13-telemetria.md`) +abarcaba **dos aspectos distintos** que nunca terminaron de definirse como uno: + +1. **Auto-observación**: que el propio sistema determine su estado para emitir + avisos o responder con acciones (salud del daemon, métricas locales, crash + reports en disco). +2. **Informe anonimizado al exterior**: export OTLP/gRPC hacia un backend + OpenTelemetry en Google Cloud (Cloud Run → BigQuery + Cloud Trace), con + Anonymizer y CLI `lnxdrive report send`, opt-in y desactivado por defecto. + +El aspecto (2) estaba de facto casi descartado desde el diseño: **uno de los +objetivos del producto es garantizar al adoptante que ningún dato sale de sus +PCs hacia sistemas del proyecto**. La propuesta de valor de LNXDrive frente a +clientes propietarios se apoya en esa garantía. Mantener el export "opt-in" en +la guía dejaba una ambigüedad de promesa: el diseño decía "puede salir" mientras +el discurso decía "nunca sale". Nada de esto se implementó +(`lnxdrive-telemetry` es un stub), así que el costo de decidir ahora es cero. + +## Decision + +**La telemetría de LNXDrive es interna-only. Se descarta formalmente todo +mecanismo de export de datos hacia el exterior.** + +1. `lnxdrive-telemetry` se re-especifica como **agente de auto-observación**: + el sistema conoce su propio estado (salud del daemon, progreso/errores de + sync, presión de recursos), emite avisos al usuario y puede disparar acciones + correctivas locales. +2. Se **elimina del diseño** (guía, plan B5): pipeline OTLP/gRPC, backend Google + Cloud (Cloud Run/BigQuery/Cloud Trace/Error Reporting), Anonymizer, y el + subcomando `lnxdrive report send`. +3. **Se conserva**: crash/error reports **locales** en + `~/.local/share/lnxdrive/reports/` (el usuario decide qué hacer con ellos, + p. ej. adjuntarlos manualmente a un issue), métricas Prometheus **locales-only** + (`127.0.0.1`, como ya prescribía la guía), logs JSON locales con retención. +4. La garantía se vuelve **verificable y absoluta**: ningún componente de + LNXDrive abre conexiones salvo hacia el proveedor de nube configurado por el + usuario. Esta propiedad pasa a ser criterio de test de seguridad + (`06-Testing/09`) y texto de promesa en la documentación pública. + +## Alternatives Considered + +### A. Mantener el export anonimizado opt-in (diseño original) +- **Pros**: datos de calidad para priorizar bugs; estándar en la industria. +- **Cons**: contradice la garantía central del producto incluso siendo opt-in + (la promesa "nada sale" deja de ser absoluta y se vuelve "nada sale si no + aceptas"); costo de infraestructura (GCloud) y de mantenimiento del pipeline; + superficie de riesgo de privacidad y cumplimiento. +- **Por qué no**: decisión del operador — la confianza del adoptante vale más + que los datos; el aspecto ya estaba "casi descartado" desde el diseño. + +### B. Reports locales con envío manual explícito (`report send` bajo demanda) +- **Pros**: punto medio; el usuario controla cada envío. +- **Cons**: sigue exigiendo backend receptor + anonimización auditada; la + promesa absoluta se diluye igual ("hay un botón que envía"). +- **Por qué no**: el valor marginal sobre "adjunta el archivo al issue de + GitHub" no justifica ni la infraestructura ni la ambigüedad de promesa. + +### C. Interna-only con artefactos locales (elegida) +- **Pros**: promesa absoluta y verificable; cero infraestructura; el aspecto (1) + —el único con valor de producto directo— se conserva íntegro; los reports + locales dan al usuario el material para reportar bugs voluntariamente. +- **Cons**: el proyecto no recibe señal pasiva de calidad desde instalaciones + reales; la priorización de bugs depende de reportes voluntarios. + +## Consequences + +**Positivas**: la garantía de privacidad es demostrable por inspección de red +(criterio de test); desaparece el costo GCloud; `lnxdrive-telemetry` queda con +un alcance implementable en v0.2; coherencia total entre discurso y diseño. + +**Negativas**: sin telemetría pasiva de campo — mitigado por el canal de issues +público y los reports locales adjuntables. + +**Neutras**: el CLI conserva `lnxdrive report list/view/delete` (gestión local); +pierde `send`. + +## Affected Components + +| Componente | Impacto | +|---|---| +| `lnxdrive-guide/04-Componentes/13-telemetria.md` | Reescritura (plan B5): interna-only, sin backend externo | +| `lnxdrive-engine/crates/lnxdrive-telemetry/` | Se implementa en v0.2 con el alcance redefinido | +| `lnxdrive-guide/06-Testing/09-testing-seguridad.md` | Nuevo criterio: ninguna conexión saliente salvo al proveedor configurado | +| CLI (`lnxdrive report …`) | `send` se retira del diseño; gestión local se conserva | + +## Implementation Plan + +1. Plan B5 (`new-guide/08-plan-actualizacion-guia.md`): reescribir el doc de + telemetría de la guía. +2. v0.2.0-beta: implementar `lnxdrive-telemetry` interna-only (junto al epic + estructural de ADR-2026-07-04-001). +3. Añadir el test de "cero conexiones salientes no-proveedor" a la estrategia + de seguridad. + +## Success Metrics + +- Guía sin ninguna referencia a OTLP/Google Cloud/Anonymizer tras B5. +- Test de red en la suite de seguridad: bajo operación completa (sync + FoD + + panel), las únicas conexiones salientes observadas apuntan al proveedor de + nube configurado. +- Documentación pública (README/landing) enuncia la garantía en absoluto: + "ningún dato sale de tu equipo hacia nosotros — no hay mecanismo para ello". + +--- + + diff --git a/.straymark/07-ai-audit/agent-logs/guide/AILOG-2026-07-04-001-gobernanza-replanteo-charter-transition.md b/.straymark/07-ai-audit/agent-logs/guide/AILOG-2026-07-04-001-gobernanza-replanteo-charter-transition.md new file mode 100644 index 0000000..b51e742 --- /dev/null +++ b/.straymark/07-ai-audit/agent-logs/guide/AILOG-2026-07-04-001-gobernanza-replanteo-charter-transition.md @@ -0,0 +1,151 @@ +--- +id: AILOG-2026-07-04-001 +title: "Gobernanza del replanteo: cierre honesto de Charter-01, Charter-02 (M0–M6), ADRs D1/D3, AIDEC D2, GitHub Milestones" +status: accepted +created: 2026-07-04 +agent: claude-code-v1.0 +confidence: high +review_required: true +risk_level: medium +eu_ai_act_risk: not_applicable +nist_genai_risks: [] +iso_42001_clause: [6, 8, 9] +lines_changed: 1100 +files_modified: + - .straymark/charters/01-road-to-v0-1-0-alpha-1.md + - .straymark/charters/CHARTER-01.telemetry.yaml + - .straymark/charters/02-road-to-functional-v0-1.md + - .straymark/02-design/decisions/ADR-2026-07-04-001-restaurar-delimitacion-crates.md + - .straymark/02-design/decisions/ADR-2026-07-04-002-telemetria-interna-only.md + - .straymark/07-ai-audit/decisions/AIDEC-2026-07-04-001-auth-por-plataforma-goa-gnome.md + - .straymark/follow-ups-backlog.md +observability_scope: none +tags: [governance, charter, replanteo, milestones, adr, aidec] +related: + - CHARTER-01-road-to-v0-1-0-alpha-1 + - CHARTER-02-road-to-functional-v0-1 + - ADR-2026-07-04-001 + - ADR-2026-07-04-002 + - AIDEC-2026-07-04-001 +--- + +# AILOG: Gobernanza del replanteo — transición Charter-01 → Charter-02 + +## Summary + +Ejecución de las acciones de gobernanza C1–C5 del plan de replanteo +(`new-guide/08-plan-actualizacion-guia.md`, aprobado en PR #61). El proyecto +transita del esquema "hito = fases completadas + tag SemVer" (que dejó a +CHARTER-01 sin cierre natural: Fase 6 inejectuable con el login roto) al esquema +de **milestones por capacidad demostrable** (M0–M6), con las decisiones del +operador D1–D4 formalizadas en ADRs/AIDEC. + +## Context + +El replanteo del 2026-07-04 (`new-guide/06-catalogo-desviaciones.md`) diagnosticó +tres desconexiones: hitos sin criterio de capacidad, testing 100% mock, y risk +backlog desconectado de milestones. El operador tomó cuatro decisiones (D1–D4) +y ordenó "gobernanza primero, luego reescritura de la guía canónica". + +## Actions Performed + +1. **C1 — Cierre honesto de CHARTER-01**: `straymark charter close` con + telemetría validada contra schema. `completed_as_planned: false`, + `scope_changes: mayor` — Fases 0–5 ejecutadas con calidad auditada; **Fase 6 + (tag) NO ejecutada porque el gate era incorrecto** (checklist de features sin + criterio de capacidad). Bloque `## Closing notes (2026-07-04)` añadido al + Charter con la trazabilidad de la redefinición (D4). FU-010/FU-011 (tag-time) + transferidos al cierre de CHARTER-02. +2. **C2 — CHARTER-02 declarado** (`02-road-to-functional-v0-1.md`, effort L, + `status: declared`): fases = milestones M0–M6; superficie load-bearing + declarada desde código LEÍDO (informes new-guide/01-05); riesgos R1–R5 con + mitigaciones de umbral concreto; cierre gateado por el tag `v0.1.0-alpha.1`. +3. **C3 — Decisiones formalizadas**: + - `ADR-2026-07-04-001` (D1): restaurar delimitación de crates — + incremental, M6 nace en `lnxdrive-conflict`, extracción de audit en v0.2. + - `ADR-2026-07-04-002` (D3): telemetría interna-only; export externo + (OTLP→Google Cloud) formalmente descartado — promesa de privacidad absoluta + y verificable. + - `AIDEC-2026-07-04-001` (D2): GOA como vía de login GNOME; PKCE loopback + como ruta universal; fallback definido si los scopes GOA no sirven (R1). + - Ambos ADRs quedan `draft` + `review_required: true` para aprobación del + operador. +4. **C4 — GitHub Milestones M0–M6 creados** (#4–#10), conservando los + milestones-paraguas por versión (#1–#3). La asignación de issues a M-hitos es + trabajo del batch M0 (los fantasmas se cierran, no se asignan). +5. **C5 — Follow-ups nuevos registrados** (sección §Follow-ups de este AILOG → + registro vía `straymark followups drift --apply` en el mismo commit). + +## Risk + +- Sin riesgo de código: cambio 100% de gobernanza/documentación. +- **R1 (proceso)**: cerrar un Charter con `completed_as_planned: false` podría + leerse como fracaso. Mitigado: las Closing notes y la telemetría explican que + es corrección de criterio, con las Fases 0–5 auditadas como entregadas. + +## Modified Files + +| File | Change | +|---|---| +| `.straymark/charters/01-road-to-v0-1-0-alpha-1.md` | status → closed; espejo actualizado; `## Closing notes (2026-07-04)` | +| `.straymark/charters/CHARTER-01.telemetry.yaml` | New — telemetría de cierre validada (3 rondas de auditoría externa, 4 emergentes, 15 follow-ups) | +| `.straymark/charters/02-road-to-functional-v0-1.md` | New — Charter-02 declarado con fases M0–M6 | +| `.straymark/02-design/decisions/ADR-2026-07-04-00{1,2}-*.md` | New — D1 y D3 formalizadas (draft, review_required) | +| `.straymark/07-ai-audit/decisions/AIDEC-2026-07-04-001-*.md` | New — D2 formalizada | +| `.straymark/follow-ups-backlog.md` | +2 entradas (drift --apply) | + +## Decisions Made + +- Los milestones por versión de GitHub (#1–#3) **se conservan** como paraguas: + M0–M6 miden capacidad; v0.2/v1.0 agrupan los epics diferidos. Un issue vive en + el M-hito que bloquea o en el paraguas de versión si está diferido. +- Los ADRs se emiten como `draft` — la aprobación es del operador + (`straymark approve`), consistente con los límites de autonomía de + AGENT-RULES §3. + +## Impact + +- **Functionality**: N/A (sin código). +- **Process**: el avance del proyecto pasa a medirse por capacidades + verificables contra OneDrive real; el risk backlog queda conectable a hitos. +- **Security/Privacy**: D3 convierte la promesa de privacidad en propiedad de + diseño verificable (criterio de test futuro, plan B5). + +## Verification + +- [x] `straymark charter status CHARTER-01-road-to-v0-1-0-alpha-1` → closed, + telemetría validada contra schema (`charter close` finalizado sin errores). +- [x] `straymark charter status CHARTER-02-road-to-functional-v0-1` → declared, + originating AILOG = este documento. +- [x] `gh api repos/StrangeDaysTech/lnxdrive/milestones` → 10 milestones + (3 versión + 7 capacidad M0–M6). +- [x] `straymark validate` limpio (0 errores) tras todos los cambios. +- [x] `straymark followups drift` en sync tras `--apply`. + +## Follow-ups + +- **Cablear el refresh de token en runtime del daemon**: `refresh_if_needed` + (`lnxdrive-engine/crates/lnxdrive-core/src/usecases/authenticate.rs:201-252`) + existe y nunca se invoca; el daemon crea el `GraphClient` una sola vez al + arrancar (`lnxdrive-daemon/src/main.rs:232`) y no maneja 401 en el loop — la + sesión muere a la ~1h. Trigger: CHARTER-02 batch M5. Destino: milestone M5 + (GitHub #9). +- **Unificar las rutas de autenticación divergentes**: el CLI usa + `GraphAuthAdapter` directo exigiendo `app_id` de config + (`lnxdrive-cli/src/commands/auth.rs:69-78`), mientras + `AuthenticateUseCase::login` usa `DEFAULT_APP_ID` pero llama a + `cloud_provider.authenticate()` que es un stub `bail!` en el provider real + (`lnxdrive-graph/src/provider.rs:165`) — ese use case no autentica de verdad; + además `redirect_uri` difiere entre rutas (`127.0.0.1:8400/callback` vs + `localhost:8400`). Trigger: CHARTER-02 batch M1. Destino: milestone M1 + (GitHub #5); diseño según AIDEC-2026-07-04-001. + +## Additional Notes + +- Este AILOG es el `originating_ailog` de CHARTER-02. +- La reescritura de la guía canónica (Fase B, B1–B10) es el siguiente bloque de + trabajo tras la aprobación de este PR; no forma parte de este AILOG. + +--- + + diff --git a/.straymark/07-ai-audit/decisions/AIDEC-2026-07-04-001-auth-por-plataforma-goa-gnome.md b/.straymark/07-ai-audit/decisions/AIDEC-2026-07-04-001-auth-por-plataforma-goa-gnome.md new file mode 100644 index 0000000..806662e --- /dev/null +++ b/.straymark/07-ai-audit/decisions/AIDEC-2026-07-04-001-auth-por-plataforma-goa-gnome.md @@ -0,0 +1,94 @@ +--- +id: AIDEC-2026-07-04-001 +title: "Auth por plataforma: GOA como vía de login en GNOME, PKCE loopback como ruta universal" +status: accepted +created: 2026-07-04 +agent: claude-code-v1.0 +confidence: high +review_required: false +risk_level: medium +eu_ai_act_risk: not_applicable +nist_genai_risks: [] +iso_42001_clause: [8] +tags: [auth, oauth, goa, pkce, gnome, multi-desktop, replanteo] +related: [ADR-2026-07-04-001, ADR-2026-07-04-002, CHARTER-02-road-to-functional-v0-1, AILOG-2026-07-04-001] +--- + +# AIDEC: Auth por plataforma — GOA en GNOME, PKCE loopback universal + +## Context + +El replanteo del 2026-07-04 (`new-guide/03-diagnostico-login.md`, +`06-catalogo-desviaciones.md` C1) encontró el login GUI roto: el daemon devuelve +en `StartAuth` una URL OAuth sin parámetros. En el código existen **dos +mecanismos de auth reales y completos** que nunca se cablearon end-to-end desde +la GUI: (a) el flujo OAuth2 Authorization Code + PKCE con callback loopback +(`lnxdrive-graph/src/auth.rs`, hoy solo usado por el CLI) y (b) el backend GOA +(GNOME Online Accounts) inyectado en el daemon +(`goa_auth_backend.rs`, endurecido en RISK-002 para no exponer tokens por D-Bus). +Al replantear M1 ("puedo entrar") hubo que decidir cuál es la vía primaria de la +GUI de GNOME, considerando que el proyecto apunta a múltiples escritorios en +v1.0 (KDE, COSMIC, XFCE/MATE — sin GOA). + +## Problem + +¿Qué ruta de autenticación dispara el botón "Sign In" de la app de preferencias +de GNOME, y qué papel juega la otra ruta — sabiendo que cada escritorio futuro +tendrá artefactos ejecutables/de configuración específicos de su plataforma? + +## Alternatives Considered + +### Alternativa A — PKCE loopback como vía primaria en todas las UIs +- **Pros**: un solo flujo que controlamos por completo; idéntico en todos los + escritorios (sirve directo a v1.0); no depende de la integración + Microsoft↔GOA de cada versión de GNOME. +- **Cons**: en GNOME ignora el SSO nativo (si el usuario ya tiene su cuenta + Microsoft en Online Accounts, le pedimos loguearse otra vez en un navegador); + experiencia menos integrada al escritorio; la guía prescribía GOA para GNOME. + +### Alternativa B — GOA como vía GNOME; PKCE loopback como ruta universal (elegida) +- **Pros**: cada escritorio usa sus artefactos nativos (principio del proyecto + multi-escritorio: en GNOME eso es GOA; en KDE será KAccounts o equivalente); + SSO real si la cuenta ya existe en Online Accounts; coherente con la guía y + con el endurecimiento RISK-002 ya invertido en el backend GOA; PKCE queda + intacto para CLI y para plataformas sin GOA. +- **Cons**: dependemos de que los tokens GOA traigan scopes utilizables para + Graph (`Files.ReadWrite.All`) — riesgo R1 de CHARTER-02, verificado como + primer gate de M1; dos rutas vivas exigen mantener ambas probadas. + +## Decision + +**Alternativa B** — decisión **D2 del operador** (2026-07-04): "debemos +considerar, respecto de los otros escritorios, que se deberán diseñar artefactos +ejecutables o de configuración específicos de esa plataforma; así que podemos +optar, en el caso de GNOME, por GOA". + +Concreción: +1. El botón de login de la app de preferencias GNOME usa la vía **GOA** + (`CompleteAuthViaGOA`, feature `goa` activa en el build shippeado). +2. El flujo **PKCE loopback** es la ruta universal: CLI hoy; vía por defecto de + los escritorios sin servicio de cuentas nativo en v1.0. El placeholder roto + de `StartAuth` se arregla poblando la URL PKCE real (deja de mentir). +3. `redirect_uri` canónico: `http://127.0.0.1:8400/callback` (se elimina la + variante `localhost:8400` de `authenticate.rs:20`). +4. Si M1 demuestra que los tokens GOA no sirven para Graph (riesgo R1), el + fallback es PKCE como vía GUI y esta decisión se re-abre con el operador. + +## Consequences + +**Positivas**: M1 tiene vía definida y verificable; el diseño por plataforma +queda enunciado como principio (cada UI usa los artefactos nativos de su +escritorio); las dos inversiones existentes (GOA endurecido + PKCE completo) +se aprovechan en lugar de elegir-y-tirar. + +**Negativas**: matriz de prueba de auth ×2 (GOA y PKCE deben mantenerse +funcionales); la promesa GNOME depende de un componente externo (GOA) cuyo +comportamiento por versión hay que vigilar. + +**Riesgos**: R1 de CHARTER-02 (scopes GOA↔Graph) — gate temprano de M1 con +fallback definido. La documentación de la guía se actualiza en el plan B7 +(`new-guide/08-plan-actualizacion-guia.md`). + +--- + + diff --git a/.straymark/charters/01-road-to-v0-1-0-alpha-1.md b/.straymark/charters/01-road-to-v0-1-0-alpha-1.md index ecfd668..68945d3 100644 --- a/.straymark/charters/01-road-to-v0-1-0-alpha-1.md +++ b/.straymark/charters/01-road-to-v0-1-0-alpha-1.md @@ -1,6 +1,7 @@ --- charter_id: CHARTER-01-road-to-v0-1-0-alpha-1 -status: in-progress +status: closed +closed_at: 2026-07-04 started_at: 2026-05-29 effort_estimate: L trigger: "MVP audit on 2026-05-28 found engine ~70% / GNOME UI ~45% ready, four P0 risks unmitigated, zero release artifacts. Operator committed scope to v0.1.0 alpha (GNOME-only, P0 risks block release) on 2026-05-29." @@ -9,7 +10,7 @@ originating_ailogs: [AILOG-2026-05-29-001] # Charter: Road to v0.1.0-alpha.1 -> **Status (mirrored from frontmatter — source of truth is above):** in-progress (started 2026-05-29). Effort: L (~5–7 calendar weeks). +> **Status (mirrored from frontmatter — source of truth is above):** closed 2026-07-04 (started 2026-05-29). Effort: L (~5–7 calendar weeks). **Closed by redefinition** — see `## Closing notes (2026-07-04)`. > > **Origin:** Follow-up of `AILOG-2026-05-29-001` — full diagnosis of the MVP state, the scope-narrowing decisions taken with the operator, and the phase outline that this Charter formalizes. @@ -161,6 +162,28 @@ This Charter executes in **multi-batch mode** (7 phases over 5–7 calendar week 10. Fase 6: signed git tag `v0.1.0-alpha.1`, `release.yml` produces bundle, publish GitHub Pre-release, announcement on r/linux + r/gnome + r/onedrive + Mastodon. 11. `straymark charter close CHARTER-01-road-to-v0-1-0-alpha-1` with telemetry comparing declared vs actual (effort estimate accuracy, R1–R5 outcomes, emergent risks count). +## Closing notes (2026-07-04) + +**Cierre por redefinición, no por consumación.** Las Fases 0–5 se ejecutaron con +calidad auditada (4 P0 de seguridad cerrados, T101 validado con mount FUSE real, +panel GTK4 verificado en VM, bundle Flatpak construible, infraestructura de +release completa). La **Fase 6 (tag firmado + pre-release + anuncios) NO se +ejecutó**: el replanteo del 2026-07-04 (`new-guide/06-catalogo-desviaciones.md`) +demostró que el gate del tag era conceptualmente incorrecto — hito definido como +checklist de features + SemVer, sin ningún criterio de capacidad — lo que permitió +llegar a "Fase 5 done" con el login GUI roto (`StartAuth` placeholder sin +parámetros), sin refresh de token en runtime y sin detección de conflictos. + +Por decisión del operador (**D4**, 2026-07-04): `v0.1.0-alpha.1` se redefine como +"**M1–M6 demostrables contra OneDrive real**" y la ejecución continúa en +**CHARTER-02 (Road to functional v0.1)**, cuyas fases son los milestones por +capacidad M0–M6 de `new-guide/07-milestones-capacidad.md`. Los ítems tag-time de +este Charter (FU-010, FU-011; fecha real en CHANGELOG y metainfo) se transfieren +al cierre de CHARTER-02. + +No es un fracaso de ejecución sino una corrección de criterio; así se registra en +`CHARTER-01.telemetry.yaml` (`completed_as_planned: false`, `scope_changes: mayor`). + ## Charter Closure When closing this Charter: diff --git a/.straymark/charters/02-road-to-functional-v0-1.md b/.straymark/charters/02-road-to-functional-v0-1.md new file mode 100644 index 0000000..ae7e1ac --- /dev/null +++ b/.straymark/charters/02-road-to-functional-v0-1.md @@ -0,0 +1,219 @@ +--- +charter_id: CHARTER-02-road-to-functional-v0-1 +status: declared +effort_estimate: L +trigger: "Replanteo aprobado el 2026-07-04 (new-guide/06-08, PR #61): CHARTER-01 cerrado por redefinición — su Fase 6 (tag) tenía un gate incorrecto (checklist de features sin criterio de capacidad). Decisión D4 del operador: v0.1.0-alpha.1 se re-gatea como 'M1–M6 demostrables contra OneDrive real'." +originating_ailogs: [AILOG-2026-07-04-001] +work_verb: implement +design_provenance: new +--- + +# Charter: Road to functional v0.1 + +> **Status (mirrored from frontmatter — source of truth is above):** declared. Effort: L (~6–8 semanas calendario). +> +> **Origin:** Follow-up of AILOG-2026-07-04-001 (gobernanza del replanteo) — sucesor directo de CHARTER-01, que cerró con Fases 0–5 ejecutadas y la Fase 6 (tag) sin ejecutar por gate incorrecto. Este Charter ejecuta la escalera de capacidades M0–M6 de `new-guide/07-milestones-capacidad.md` y termina cortando el tag `v0.1.0-alpha.1`. + +## Context + +CHARTER-01 entregó las piezas (motor Graph, FUSE, stack GNOME, packaging Flatpak, +infraestructura de release) pero el sistema no funciona end-to-end: el login GUI +está roto (`StartAuth` devuelve una URL OAuth sin parámetros), el daemon no +refresca el token en runtime (muere a la ~1h), y no existe detección de +conflictos (riesgo last-writer-wins). El replanteo del 2026-07-04 +(`new-guide/06-catalogo-desviaciones.md`) diagnosticó tres desconexiones: hitos +sin criterio de capacidad, testing 100% contra mock, y risk backlog desconectado +de los milestones. + +Este Charter corrige las tres: sus fases **son** milestones por capacidad +(cada una demostrable por el operador contra OneDrive real, con guion de +verificación), ninguna capacidad se cierra contra mock, y los issues del risk +backlog se asignan a la fase que bloquean (GitHub Milestones M0–M6). Aplican las +decisiones del operador D1 (funciones delimitadas por crate: la detección de +conflictos nace en `lnxdrive-conflict`), D2 (GOA como vía de login GNOME; PKCE +loopback como ruta universal) y D4 (el tag es consecuencia, no hito). + +## Scope + +**In scope:** + +1. **M0 — "Sé qué es verdad"**: triage de re-verificación de los 23 issues + abiertos (`from-risk-analysis`) contra el código actual. Sospechosos de estar + ya resueltos: #9 (`sync_item.rs:768` permite `Error → *`), #14 (`engine.rs:442` + maneja `410 Gone → full resync`), #21 (solapamiento parcial con ISSUE-002 + cerrado). Cada fantasma se cierra con nota de verificación; el resto se asigna + al milestone de GitHub que bloquea. +2. **M1 — "Puedo entrar"**: login real con cuenta Microsoft desde la app de + preferencias vía **GOA** (D2); tokens al keyring; la UI muestra la cuenta. + Incluye: build shippeado con feature `goa` activa, arreglo del placeholder + `StartAuth` (PKCE como ruta universal/CLI), consolidación del `redirect_uri` + (`http://127.0.0.1:8400/callback` vs `localhost:8400`) y del origen del + `app_id` (default vs config). Verifica de paso que los tokens GOA traen scopes + utilizables para Graph. +3. **M2 — "Veo mis archivos"**: tras login, el delta inicial puebla placeholders + del OneDrive real del operador; `lnxdrive status` refleja cuenta y conteo. +4. **M3 — "Abro un archivo"**: hidratación on-demand real desde Nautilus + (placeholder → descarga → abre; xattr/estado correctos). +5. **M4 — "Mis cambios viajan"**: bidireccional demostrado — edición local + aparece en OneDrive web; edición remota baja. +6. **M5 — "Sobrevive el tiempo"**: daemon 24h+ con sesión activa — cablear + `refresh_if_needed` (hoy definido y jamás invocado) + manejo de 401 en el + sync loop; sin reinicios manuales. +7. **M6 — "No destruye datos"**: detección de conflicto simultáneo local+remoto, + materializado sin pérdida silenciosa (resolución mínima: keep-both). + **Implementado en `lnxdrive-conflict`** (D1) consumiendo los tipos de dominio + de core. Los P0 de data-integrity (#8, #12, #13) llegan aquí verificados o + resueltos. +8. **Cierre = tag**: con M1–M6 demostrados, fecha real en `CHANGELOG.md` y + metainfo (FU-010/FU-011, transferidos de CHARTER-01), tag firmado + `v0.1.0-alpha.1`, pre-release de GitHub con bundle + SHA256SUMS, anuncios. + +**Out of scope:** + +- Todo el epic "distribuible" de v0.2.0-beta (Flathub/vendoring FU-003/FU-008, + RPM/DEB/AUR/AppImage, grupo System, Unix-socket fallback, i18n, tarpaulin + formal) — hereda los diferimientos de CHARTER-01 sin cambios. +- Epic estructural "restaurar delimitación de crates" para lo YA implementado + (extracción de audit desde core; implementación de telemetry redefinida por + D3) — v0.2.0-beta. M6 no lo adelanta: solo la funcionalidad NUEVA nace en su + crate. +- FU-007 (IPC FoD para `pin/hydrate/…` del CLI) — v0.2.0-beta; no bloquea + ninguna capacidad M1–M6 (la hidratación de M3 va por FUSE, no por CLI). +- UIs de `experimental/`, multi-proveedor, 5+ idiomas — v1.0.0. +- Resolución de conflictos avanzada (reglas YAML, UI de resolución, Meld) — M6 + entrega detección + keep-both; lo demás es post-v0.1. + +## Files to modify + +Charter multi-batch (7 milestones); la tabla nombra las superficies load-bearing +verificadas por lectura en los informes `new-guide/01-05` (2026-07-03/04). Los +milestones M2–M4 son mayormente de *verificación* sobre código existente: su +superficie de fix exacta se descubre al ejecutar y se documenta por el patrón de +actualización atómica (convención 5). + +| File | Change | +|---|---| +| `lnxdrive-engine/crates/lnxdrive-ipc/src/service.rs` | M1: `AuthInterface::start_auth` deja de devolver el placeholder sin parámetros (`:849-863`); ruta GOA verificada end-to-end; PKCE poblando `state.auth_url` como vía universal | +| `lnxdrive-engine/crates/lnxdrive-graph/src/auth.rs` | M1: consolidar `REDIRECT_URI` (`:32`) con `authenticate.rs:20`; M5: reuso de `PKCEFlow::refresh_token` / `refresh_via_goa` desde el daemon | +| `lnxdrive-engine/crates/lnxdrive-core/src/usecases/authenticate.rs` | M1: resolver la divergencia de rutas (el use case llama `cloud_provider.authenticate()` que es `bail!` en el provider real); M5: `refresh_if_needed` (`:201`) por fin invocado | +| `lnxdrive-engine/crates/lnxdrive-daemon/src/main.rs` | M5: el `GraphClient` deja de crearse una sola vez con token fijo (`:232`); refresh/re-auth en el loop | +| `lnxdrive-gnome/preferences/src/onboarding/auth_page.rs` + `lnxdrive-gnome/preferences/Cargo.toml` | M1: camino GOA (`#[cfg(feature = "goa")]`) activo en el build shippeado; UX de error si GOA ausente | +| `lnxdrive-engine/crates/lnxdrive-sync/src/engine.rs` | M4: fixes que surjan de la verificación real; M6: hook de detección de conflictos antes de upload (`:1268` hoy compara solo hash local vs almacenado) | +| `lnxdrive-engine/crates/lnxdrive-conflict/src/lib.rs` | M6: New (deja de ser stub) — detección + materialización keep-both, consumiendo tipos de dominio de core (D1) | +| `lnxdrive-engine/crates/lnxdrive-cache/src/repository.rs` | M6: persistencia de conflictos detectados (métodos ya existentes en `IStateRepository`) | +| `CHANGELOG.md` + `lnxdrive-gnome/preferences/data/com.strangedaystech.LNXDrive.Preferences.metainfo.xml.in` | Cierre: fecha real del tag (FU-010/FU-011) | +| `new-guide/09-guiones-verificacion.md` | New: guion de verificación por milestone, escrito al ABRIR cada batch (regla 2 del replanteo) | +| `.straymark/07-ai-audit/agent-logs/{daemon,gnome}/AILOG-*.md` | New: un AILOG por milestone/batch, `risk_level` según fase (medium M1/M5/M6; low M0/M2–M4) | + +## Verification + +### Local checks + +```bash +# Build & test — engine y preferences compilan y pasan en checkout limpio +cd lnxdrive-engine && cargo test --workspace && cargo clippy --workspace --all-targets -- -D warnings +cd ../lnxdrive-gnome/preferences && cargo build --features goa + +# Gobernanza — Charter válido, sin drift no documentado +straymark validate +straymark charter drift CHARTER-02-road-to-functional-v0-1 --range origin/main..HEAD + +# M0 — cada issue cerrado como fantasma referencia file:line del código que lo resuelve +gh issue list --state closed --search "verificado" --limit 30 +``` + +### Capability gates (operador, OneDrive real — no ejecutables sin cuenta) + +Guiones completos en `new-guide/09-guiones-verificacion.md` (se escriben al abrir +cada batch). Resumen del gate por milestone: + +```bash +# M1: app de preferencias → Sign In (GOA) → cuenta visible; tokens SOLO en keyring +secret-tool search service lnxdrive # token presente +dbus-monitor --session | grep -cE "Bearer|eyJ" # 0 apariciones + +# M2: tras login, placeholders reales +lnxdrive status --json | jq '.account, .items_total' # cuenta + conteo > 0 + +# M3: hidratar desde Nautilus un placeholder y verificar estado +getfattr -n user.lnxdrive.state # hydrated + +# M4: tocar archivo local → aparece en OneDrive web; editar remoto → baja +# M5: daemon 24h+ (journalctl --user -u lnxdrive) sin reinicio, token renovado +# M6: editar el MISMO archivo local y remoto en <1 ciclo de sync → +# ambos contenidos sobreviven (keep-both), estado Conflicted visible +``` + +## Risks + +- **R1 — Los tokens GOA no traen scopes utilizables para Graph** (`Files.ReadWrite.All`). + Probabilidad media, severidad alta (invalida la vía D2 para M1). + Mitigación: es lo PRIMERO que M1 verifica contra cuenta real (gate temprano, + primera semana). Si falla: fallback a PKCE loopback daemon-owned como vía GUI + (los dos caminos ya existen en código), GOA se re-evalúa como SSO de solo-identidad, + y la decisión D2 se re-abre con el operador antes de continuar. +- **R2 — M6 (conflictos) explota el presupuesto** — es la única capacidad sin base + implementada. Probabilidad media, severidad media. + Mitigación: alcance mínimo inflexible (detección + keep-both; nada de reglas/UI); + si al cabo de 2 semanas de batch no hay gate M6, se divide: M6a detección-only + cierra el Charter con keep-both manual documentado, M6b pasa a v0.2. El tag no + se corta sin al menos M6a. +- **R3 — Los P0 de data-integrity (#8/#12/#13) exigen cirugía de engine mayor a lo + presupuestado.** Probabilidad media, severidad alta. + Mitigación: M0 los re-verifica y dimensiona ANTES de agendar (primera semana); + si alguno requiere >1 semana, se presenta al operador con opciones (bloquear + tag vs documentar como known-limitation del alpha) — decisión explícita, no + deriva silenciosa. +- **R4 — Drift declarado-vs-tocado** (constante en Charters largos). Probabilidad + alta, severidad baja. + Mitigación: `straymark charter drift` pre-commit por batch (Tasks #8); + desviaciones al AILOG como `R (new, not in Charter)` + actualización + atómica de `## Files to modify` en el mismo PR. +- **R5 — Throttling/limitaciones de la API real de Microsoft durante verificación + intensiva.** Probabilidad media, severidad baja. + Mitigación: cuenta de pruebas dedicada; el `AdaptiveRateLimiter` ya implementado + gestiona 429; los guiones de verificación espacian operaciones. Si un gate se + vuelve no-determinista por throttling, se documenta el patrón y se repite en + ventana distinta — nunca se marca pasado sin observarlo. + +## Tasks + +Ejecución **multi-batch** (7 batches = M0…M6). Tras el merge del PR de cada batch: +`straymark charter batch-complete CHARTER-02-road-to-functional-v0-1 `. + +1. Sync `main`, branch por batch (`fix/m1-…`, `feat/m6-…` según el caso). +2. Al ABRIR cada batch: escribir el guion de verificación del milestone en + `new-guide/09-guiones-verificacion.md` (ex-ante, regla 2). +3. M0: triage de 23 issues → cerrar fantasmas con evidencia file:line, asignar + el resto a GitHub Milestones M1–M6 (o v0.2/backlog). +4. M1…M6: implementar/verificar según Scope; el batch NO se cierra hasta que el + operador ejecuta el gate de capacidad contra OneDrive real y lo confirma. +5. AILOG por batch (`risk_level` según tabla) con `## Batch Ledger` mantenido. +6. Pre-commit por batch: `straymark charter drift CHARTER-02-road-to-functional-v0-1`. +7. Registrar en el registro de follow-ups los emergentes de cada batch + (`straymark followups drift --apply` antes de commitear el AILOG). +8. Cierre: FU-010/FU-011 (fechas) → tag firmado `v0.1.0-alpha.1` → pre-release + GitHub → anuncios (r/linux, r/gnome, r/onedrive, Mastodon) → + `straymark charter close` con telemetría. + +## Charter Closure + +When closing this Charter: + +1. **Atomic update (format v4)**: si el drift check reportó desviaciones no + capturadas en los AILOGs de batch, editar `## Files to modify` y/o añadir + `## Closing notes` en el mismo commit/PR del cierre. +2. **Post-merge drift check**: `straymark charter drift CHARTER-02-road-to-functional-v0-1 --range origin/main..HEAD`. +3. **Status frontmatter** → `closed` + `closed_at`; telemetría con el comando + `straymark charter close` (comparar estimación L vs real; resultados R1–R5; + conteo de emergentes). +4. **El tag es el gate**: este Charter no cierra sin `v0.1.0-alpha.1` publicado + — o sin una decisión explícita del operador que re-defina el cierre (como le + ocurrió a CHARTER-01; si sucede dos veces, el formato de milestones se + re-examina en la retro). +5. **No borrar** este archivo. + + diff --git a/.straymark/charters/CHARTER-01.telemetry.yaml b/.straymark/charters/CHARTER-01.telemetry.yaml new file mode 100644 index 0000000..3126a61 --- /dev/null +++ b/.straymark/charters/CHARTER-01.telemetry.yaml @@ -0,0 +1,120 @@ +# StrayMark Charter telemetry — CHARTER-01, filled at close (2026-07-04). +# Schema: .straymark/schemas/charter-telemetry.schema.v0.json +# Principio aplicado: gaps honestos > números inventados. Los conteos no medidos +# van en 0 con nota; las aproximaciones se marcan como tales. + +charter_telemetry: + # ---------- Identification ---------- + charter_id: "CHARTER-01" + charter_title: "Road to v0.1.0-alpha.1" + closed_at: "2026-07-04" + + # ---------- Origin & activation ---------- + originating_ailogs: + - ailog_id: "AILOG-2026-05-29-001" + still_relevant_at_execution: true + relevance_notes: "El diagnóstico (engine ~70%, GNOME ~45%, 4 P0 sin mitigar, cero artefactos de release) se sostuvo durante toda la ejecución; el outline de fases se ejecutó 0–5 tal como se declaró. Lo que NO capturó el AILOG: que el gate terminal (tag por checklist de features) era conceptualmente incorrecto — eso emergió en el replanteo del 2026-07-04." + + trigger: + declared_kind: "event_trigger" + declared_description: "Auditoría del MVP (2026-05-28) + decisión del operador (2026-05-29) de embarcar un alpha enfocado GNOME-only con los P0 como bloqueantes de release." + fired_at: "2026-05-29" + fire_clarity: "clear" + fire_clarity_notes: "Decisión explícita del operador tras auditoría; sin ambigüedad." + + # ---------- Pre-work ---------- + pre_work: + items_declared: 0 + items_completed_before_planning: 0 + items_skipped: 0 + items_discovered_during_planning: 0 + pre_work_quality: "medium" + pre_work_notes: "El formato v4 de este Charter no tenía sección §Pre-trabajo. El pre-work de facto fue la auditoría del 2026-05-28 (AILOG-2026-05-29-001). Calidad media: excelente para código/riesgos, ciega al defecto del gate (ningún criterio de capacidad)." + + # ---------- Planning session ---------- + planning_session: + occurred: true + duration_minutes: 0 + participants: 1 + decisions_made: 3 + decisions_deferred: 0 + notes: "Sesión operador+agente 2026-05-28/29: (1) alcance estrechado a alpha GNOME-only; (2) UIs GTK3/Plasma/COSMIC archivadas a experimental/; (3) P0s bloquean release. Duración no medida (0 = sin dato)." + + # ---------- Effort ---------- + effort: + started_at: "2026-05-29" + finished_at: "2026-07-04" + estimated_effort: "L (~5–7 semanas)" + actual_effort: "L (~5.3 semanas, 6/7 fases ejecutadas)" + estimation_drift_factor: 1.0 + estimation_drift_reason: "En TIEMPO dentro de presupuesto. El drift real es de ALCANCE, no de tiempo: la fase terminal (Fase 6, tag+release+anuncio) no se ejecutó porque su gate resultó incorrecto — ver outcome.scope_change_notes." + + # ---------- Agent quality during execution ---------- + agent_quality: + sessions_count: 0 + hallucinations_caught: 0 + hallucination_categories: [] + decisions_contradicting_prior_adrs: 0 + contradiction_notes: "sessions_count/hallucinations no medidos sistemáticamente durante el Charter (0 = sin dato, no 'cero eventos'). Trazable: ~15 AILOGs de ejecución en agent-logs/{daemon,gnome,guide,packaging}/." + context_loaded_was_sufficient: true + additional_context_loaded_manually: 0 + r_n_plus_one_emergent_count: 4 + skill_prompts_used: ["straymark-ailog", "straymark-audit-prompt", "straymark-audit-execute", "straymark-audit-review", "straymark-followups"] + + # ---------- External audit ---------- + external_audit: + - auditor: "ronda multi-modelo Fase 1 (heterogénea, ≥2 auditores)" + findings_total: 0 + findings_by_category: + hallucination: 0 + implementation_gap: 0 + real_debt: 0 + false_positive: 0 + audit_quality: "high" + audit_notes: "Conteos por hallazgo no preservados en formato telemetría (0 = sin dato). Efecto trazable: backport atómico R4 de las filas RISK-003/RISK-001/ISSUE-002 en ## Files to modify." + - auditor: "pre-merge Fase 3 (panel GTK4)" + findings_total: 1 + findings_by_category: + hallucination: 0 + implementation_gap: 1 + real_debt: 0 + false_positive: 0 + audit_quality: "high" + audit_notes: "1 Medium, corregido pre-merge. Consolidado en .straymark/audits/CHARTER-01/fase-3/review.md." + - auditor: "ronda multi-modelo Fases 4–5 (2026-07-03)" + findings_total: 6 + findings_by_category: + hallucination: 0 + implementation_gap: 2 + real_debt: 4 + false_positive: 0 + audit_quality: "high" + audit_notes: "H1 (wiring files-on-demand del CLI = FU-007), M2 (app-id Flatpak = FU-008), RD-2/3/4 (dep git remota = FU-009 cerrado; fechas tag-time = FU-010/011). + R1 emergente (copy overstatement, remediado pre-tag). Ver AILOG-2026-07-03-001." + + # ---------- Outcome & follow-ups ---------- + outcome: + completed_as_planned: false + scope_changes: "mayor" + scope_change_notes: "F1 (IG): Fase 6 (tag firmado v0.1.0-alpha.1 + pre-release + anuncios) NO ejecutada — el gate del tag era conceptualmente incorrecto: hito definido como checklist de features + SemVer sin ningún criterio de capacidad, lo que permitió llegar a 'Fase 5 done' con el login GUI roto (StartAuth placeholder), sin refresh de token en runtime y sin detección de conflictos. Cierre por REDEFINICIÓN (decisión D4 del operador, 2026-07-04): el alpha se re-gatea como 'M1–M6 demostrables contra OneDrive real' y la ejecución pasa a CHARTER-02. No es fracaso de ejecución sino corrección de criterio; las Fases 0–5 entregaron con calidad auditada. F2: el GitHub project board del scope item 1 se creó y luego se eliminó como redundante (operador único; tracking en StrayMark + Issues). F3: drifts de alcance por fase documentados atómicamente en su momento (R6 superficie RISK-003, R7 main.rs/ipc en RISK-001, R8 Platform 47→49)." + new_followups_generated: 15 + new_charters_created: 1 + charters_invalidated: 0 + associated_stage_id: "" + + # ---------- Qualitative ---------- + qualitative: + format_iteration: "v4" + friction_points: + - "Hito terminal = checklist de features + tag SemVer, sin criterios de aceptación por capacidad — el defecto raíz que dejó el Charter sin cierre natural" + - "Toda la pirámide de testing corre contra mock (incl. mock-dbus-daemon.py que fingía el login completo): estructuralmente imposible falsificar 'funciona'" + - "Risk backlog público (23 issues, 5 P0) desconectado de los milestones — ningún tag lo tenía como gate" + - "Validador StrayMark vs AILOGs en subdirectorios por componente (FU-015, deuda de tooling upstream)" + wins: + - "4 riesgos P0 de seguridad cerrados con auditoría externa multi-modelo (RISK-001/002/003, ISSUE-002)" + - "T101: primer mount FUSE real del codebase — destapó 4 bugs funcionales de listing + 1 defecto de persistencia de inodes, todos corregidos con regresión" + - "Patrón de actualización atómica del Charter ante drift funcionó de verdad (R6/R7/R8 backporteados en el mismo PR)" + - "Registro de follow-ups adoptado y vivo (15 entradas trazables, 9 cerradas al cierre del Charter)" + - "Arquitectura hexagonal validada por la implementación: el replanteo 2026-07-04 no tocó ni un puerto" + overall_satisfaction: 3 + would_repeat_format: true + proposed_format_changes: "Añadir criterios de aceptación por CAPACIDAD (guion de verificación ex-ante, 'el operador puede demostrar X contra el servicio real') a cada fase; regla dura: ningún hito de capacidad se cierra contra mock. Aplicado en CHARTER-02 (fases M0–M6). Ver new-guide/07-milestones-capacidad.md." diff --git a/.straymark/follow-ups-backlog.md b/.straymark/follow-ups-backlog.md index 9ed5f5f..b056ccc 100644 --- a/.straymark/follow-ups-backlog.md +++ b/.straymark/follow-ups-backlog.md @@ -1,7 +1,7 @@ --- -last_scan: 2026-07-03 +last_scan: 2026-07-04 schema_version: v1 -total_open: 6 +total_open: 8 total_promoted: 0 total_closed_in_session: 9 total_phase_blocked: 0 @@ -20,6 +20,7 @@ fully_extracted_ailogs: - AILOG-2026-07-03-001 - AILOG-2026-07-03-002 - AILOG-2026-07-03-003 + - AILOG-2026-07-04-001 --- # Follow-ups Backlog @@ -176,6 +177,25 @@ Entry shape (v1 — optional fields marked): - **Destination**: TBD - **Cost**: TBD - **Notes**: Auto-appended by `straymark followups drift --apply` 2026-07-03. + +### FU-016 — **Cablear el refresh de token en runtime del daemon**: `refresh_if_needed` +- **Origin**: AILOG-2026-07-04-001 §Follow-ups +- **Source-hash**: 4e825cf1a679 +- **Status**: open +- **Trigger**: CHARTER-02 batch M5 +- **Destination**: milestone M5 (GitHub #9) / lnxdrive-daemon +- **Cost**: M +- **Notes**: Auto-appended by `straymark followups drift --apply` 2026-07-04. Gap más crítico para uso prolongado: el daemon carga el token una vez y muere a la ~1h; `refresh_if_needed` definido y jamás invocado. + +### FU-017 — **Unificar las rutas de autenticación divergentes**: el CLI usa +- **Origin**: AILOG-2026-07-04-001 §Follow-ups +- **Source-hash**: 5295086025bb +- **Status**: open +- **Trigger**: CHARTER-02 batch M1 +- **Destination**: milestone M1 (GitHub #5) / diseño AIDEC-2026-07-04-001 +- **Cost**: M +- **Notes**: Auto-appended by `straymark followups drift --apply` 2026-07-04. Incluye: `StartAuth` placeholder, `AuthenticateUseCase` → `bail!` stub, `redirect_uri` divergente, origen del `app_id`. + ## Bucket: time-triggered ## Bucket: charter-triggered