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

オープン
  • 何か問題がありますか？
#42 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
git, shell
領域
cli, tooling

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Shell
スター
16
フォーク
6
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DimitriGeelen/agentic-engineering-framework のほかの issue

DimitriGeelen/agentic-engineering-framework の issue をすべて見る

似ている issue

Shell/Bash の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。