La decisión abierta
Hoy una corrección manual (finance correct) no se convierte en regla de categorización. Es a propósito: las reglas aprendidas de un solo caso tienden a generalizar mal y a categorizar en silencio cosas que deberían quedar "Por revisar".
Pero después de seis meses de correcciones repetidas sobre el mismo comercio, el argumento se debilita.
Propuesta para discutir
- Comando
finance rules suggest: lee corrections y propone reglas para comercios corregidos ≥ N veces a la misma categoría, sin excepciones en contra.
- Nunca escribe en
merchant_rules.yml solo. Imprime el YAML y el usuario lo pega (o --apply explícito, con confirmación).
- Cada regla sugerida trae evidencia: cuántas correcciones, en qué meses, desde qué cuentas.
Preguntas
- ¿N = 3 es razonable? ¿Debe depender del número de meses?
- ¿Una sola corrección contraria invalida la sugerencia, o basta con mayoría?
- ¿Las reglas sugeridas van con prioridad propia (por ejemplo 55) para que las escritas a mano siempre ganen?
Opiniones de quien ya use el sistema en el día a día valen doble.
La decisión abierta
Hoy una corrección manual (
finance correct) no se convierte en regla de categorización. Es a propósito: las reglas aprendidas de un solo caso tienden a generalizar mal y a categorizar en silencio cosas que deberían quedar "Por revisar".Pero después de seis meses de correcciones repetidas sobre el mismo comercio, el argumento se debilita.
Propuesta para discutir
finance rules suggest: leecorrectionsy propone reglas para comercios corregidos ≥ N veces a la misma categoría, sin excepciones en contra.merchant_rules.ymlsolo. Imprime el YAML y el usuario lo pega (o--applyexplícito, con confirmación).Preguntas
Opiniones de quien ya use el sistema en el día a día valen doble.