Add .vscode/ to .gitignore (sister concern from #2)

[kiki830621]

Problem

.vscode/ 在 work tree 裡是 untracked，且不在 .gitignore 中，所以每次 git status 都會把它
列為未追蹤檔案：

?? .vscode/

它是編輯器的本機設定，不屬於這個 repo 的產物。留著會有兩個後果：git status 永遠有一行雜訊
（真正該注意的未追蹤檔案容易被淹沒），以及某次 git add -A 會把個人編輯器設定意外推上去。

Type

chore

Expected

.gitignore 加一行 .vscode/，git status 在乾淨的 work tree 上輸出乾淨。

若日後決定要共享部分 VS Code 設定（例如 extensions.json 推薦清單），再用 ! 反向 un-ignore
個別檔案。

Actual

.gitignore 沒有 .vscode/ 規則，該目錄以 untracked 狀態常駐。

Impact

• 單檔改動、零風險。
• 與 Usage 1 needs a command you can just type, not a file you copy #2 無關，不需等 Usage 1 needs a command you can just type, not a file you copy #2 的任何決定。

Source: surfaced during /idd-diagnose #2 sister concern surfacing (Step 3.6)

Clarity Surface

Type	Source	Question for you	Status
(none)	—	no issues detected	passed

---

Current Status

Phase: verified
Last updated: 2026-09-01 by idd-all (direct-commit, attended)

Key Decisions

• Issue premise was already false: .vscode/launch.json was committed in f1f1a27 (a Usage 1 needs a command you can just type, not a file you copy #2 commit) — the git add -A accident this issue was filed to prevent had already happened
• launch.json kept deliberately (portable: only ${workspaceFolder:...} + repo targets); pattern per the issue's own ! prescription
• First implementation was inert — .vscode/ excludes the directory so the ! never evaluates; fixed to .vscode/*. Proven in a scratch repo, not by reading

Scope Changes

• One line → one block, because the ignore alone would not have addressed the tracked file

Blocking

• (none) — verified, awaiting close

Commits

[kiki830621]

Diagnosis

Type

chore

Root Cause / Analysis

The issue's premise no longer holds, and it failed in the direction the issue warned about.

git status is clean for .vscode/ — but not because the problem went away. git ls-files
reports .vscode/launch.json as tracked, committed in f1f1a27
(fix: close round 3's three CRITICALs … (#2)). It is not untracked noise; it is in the repo.

The issue body names exactly this risk:

某次 git add -A 會把個人編輯器設定意外推上去

That already happened, in a commit whose subject is about something else entirely — the
signature of a git add -A sweep.

This changes the fix. .gitignore does not affect already-tracked files, so adding
.vscode/ alone would:

• leave launch.json tracked and still appearing in every diff — the stated symptom untouched
• produce a tracked file inside an ignored directory, which reads as a mistake to anyone who
  looks later

Impact

• .gitignore — one block rather than one line
• .vscode/launch.json — its disposition has to be decided, not left implicit

Strategy

The issue already prescribes the pattern for the case where a .vscode/ file should be
shared:

若日後決定要共享部分 VS Code 設定（例如 extensions.json 推薦清單），再用 ! 反向 un-ignore 個別檔案

launch.json qualifies. Inspected: it contains only ${workspaceFolder:omlx-connector} (a VS
Code variable, portable) and this repo's own build targets. No machine paths, no personal data,
nothing that differs per developer. It is a repo artifact that happens to live under .vscode/,
and deleting it would cost every contributor the debug configs.

• Ignore .vscode/ — the directory as a whole
• ! un-ignore .vscode/launch.json — deliberate, with the reason in a comment
• Verify git check-ignore says the directory is ignored and that one file is not
• Verify launch.json is still tracked and git status stays clean
• Verify a new file under .vscode/ is ignored — the property the issue actually wants

Reversible in one line if the operator would rather drop it: delete the ! line and
git rm --cached .vscode/launch.json.

Conflict Class

C_shared_module_coord — shared resource: .gitignore. #13 named this same file and is
now closed, so there is no live contention; recorded because the classification is about the
resource, not about whether anyone happens to be touching it right now.

Complexity

Simple

One file, one obvious approach once the tracked-file fact is known, no ordering dependency, no
risk-sensitive boundary. The only thing that made it non-obvious was a fact about repo state,
not about design — which is what diagnose is for.

Risks

• Adding only the ignore line and calling it done — the failure this diagnosis exists to
  prevent. The symptom would be unchanged and the state would be worse.
• Un-ignoring by directory rather than by file (!.vscode/*) would re-admit everything and
  defeat the point.

Residue

(none) — the disposition of launch.json is decided here and the pattern generalizes to any
future shared .vscode/ file.

[kiki830621]

Implementation Complete

Checklist

• Ignore .vscode/ — the directory as a whole
  — changed during implementation: the pattern is .vscode/*, not .vscode/. See Verify.
• ! un-ignore .vscode/launch.json — deliberate, with the reason in a comment
• Verify git check-ignore says the directory is ignored and that one file is not
  — with --no-index, which is the only honest check when the file is already tracked
• Verify launch.json is still tracked and git status stays clean
• Verify a new file under .vscode/ is ignored — the property the issue actually wants
  — .gitignore:32:.vscode/* matches settings.json

Commits

• abc7923 — chore: ignore .vscode/ but keep the shared launch.json (#4)

[kiki830621]

Verify

Result: PASS — after the first implementation was found inert and replaced.

The first version was a rule that could never fire

Written as:

.vscode/
!.vscode/launch.json

It appeared correct: git check-ignore .vscode/launch.json reported not ignored, exactly as
intended. That reading was an artefact. launch.json is already tracked, and
git check-ignore skips tracked paths unless given --no-index — so the command was reporting
the tracking status, not the rule.

Tested in a scratch repo instead, with both files untracked:

pattern	launch.json	settings.json	files visible to git status
.vscode/	IGNORED	IGNORED	0
.vscode/*	kept	IGNORED	1

Git does not enumerate an excluded directory, so patterns for files inside it are never
evaluated — the ! line was inert. The fix is to glob the contents (.vscode/*) so git still
descends. Same trap as the .claude/.idd/ carve-out chain discussed in #13.

This is the failure shape this repo's CLAUDE.md keeps recording: coverage-shaped and inert,
passing because of an unrelated fact rather than because it works.

Checks after the fix

#	Check	How	Result
1	A new file under .vscode/ is ignored	check-ignore -v --no-index settings.json	✓ .gitignore:32:.vscode/*
2	launch.json is not ignored	check-ignore -q --no-index	✓ no rule matches
3	launch.json still tracked	git ls-files .vscode/	✓
4	Working tree clean	git status --porcelain	✓
5	Pattern proven in isolation	scratch repo, both patterns	✓ table above

Check 5 is the one that matters. Checks 1–4 all passed against the broken pattern too,
because they were run in a repo where the file's fate was already decided by tracking.

Verification method

The 6-AI ensemble was not run — this session operates under a constraint against spawning
review agents unless requested. The scratch-repo comparison is direct evidence about the
mechanism, which is what the defect was about.

Commit

abc7923