fw doctor should assert no tracked path matches an ignore rule (a gitignore line for a tracked file is inert)

Abierto
  • ¿Algo no está bien?
#42 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
git, shell
Área
cli, tooling

Línea de trabajo

Start by reading the fw doctor implementation and its existing checks, then inspect how it invokes Git; the issue names git ls-files and git check-ignore --stdin --no-index as the proposed check. The requested work also discusses changes to fw init and audit filtering, so confirm the intended scope with maintainers. Done when tracked paths matched by ignore rules are reported with a git rm --cached fix.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

A .gitignore rule that names an already-tracked path is inert, and nothing in the framework
notices. fw doctor should assert that the set of tracked paths and the set of ignored paths do
not intersect.

What we measured

In a project on 1.6.769, .context/working/.gitignore has carried these lines since T-1005:

watchtower.log
watchtower.pid
watchtower.port
watchtower.url

git ls-files .context/working returned watchtower.pid, watchtower.port and watchtower.url
anyway. T-1005 wrote the rules but never ran git rm --cached, so for months the rule sat beside
three files it had no effect on. Consequences: the port file was committed on every Watchtower
restart, and watchtower.url carried a LAN address (http://192.168.10.107:3000) in the
repository. Same shape for .approval-notified, .auto-restart-pending and .handover-cooldown,
which agents/context/post-compact-resume.sh:73-76 deletes on every compaction — three staged
deletions per compaction, permanently.

Note that git check-ignore hides this by default: it does not report tracked files unless you
pass --no-index. So the obvious manual check comes back clean.

Why this matters beyond one project

The framework had already routed around the symptom rather than fixing it.
agents/audit/audit.sh:3724 maintains _SESSION_STATE_FILTER:

_SESSION_STATE_FILTER='^\.context/(working/(watchtower\.|session\.yaml|focus\.yaml|...|\.approval-notified|\.restart-requested|...)|audits/|...)'

That is a second, hand-maintained list of volatile paths, in a shell regex, used to filter these
files out of the audit's "uncommitted changes present" warning. So two lists exist — one in
.gitignore, one in audit.sh — that must agree, are written in different languages, live in
different files, and are never compared. The audit suppressed the noise; the noise stayed, and
the ignore rule that was supposed to prevent it never ran.

This is the same shape as the template→CLAUDE.md cross-reference in #41, and the same lesson a
project-level learning already records: a cross-reference from code into a document rots silently
unless a check spans both.

Asks, in order of leverage

  1. fw doctor check: no tracked path matches an ignore rule. One line, catches every future
    instance in every project:

    git ls-files > /tmp/t && git check-ignore --stdin --no-index < /tmp/t

    Non-empty output is the finding. Report the paths and the fix (git rm --cached <path>).

  2. Make fw init / the ignore-writing path untrack what it ignores. When a rule is added for
    a path that is already in the index, git rm --cached it in the same operation, or refuse and
    say so. Writing a rule that cannot take effect is worse than writing none, because it reads
    like enforcement.

  3. Derive _SESSION_STATE_FILTER from the gitignore instead of duplicating it. If the audit
    needs to know which paths are volatile session state, the gitignore already says so — and once
    ask 1 holds, the two can no longer disagree. Failing that, add a test that asserts every path
    in the filter is covered by an ignore rule.

Environment

  • Framework 1.6.769, shared-tooling mode
  • Fixed locally in the project as T-1120; the six paths are untracked and the intersection
    assertion is now a P-011 verification line there.
Lenguaje dominante
Shell
Estrellas
16
Forks
6
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DimitriGeelen/agentic-engineering-framework

Todos los issues de DimitriGeelen/agentic-engineering-framework

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.