feat: gitnexus:keep marker preserves custom context sections

[dp-web4]

Summary

When <!-- gitnexus:keep --> is placed inside the GitNexus-generated block in CLAUDE.md or AGENTS.md, analyze only updates the stats line (node/edge/flow counts) instead of replacing the entire section with the verbose default template.

This lets users trim the auto-generated context to a lean custom format without it being overwritten on every reindex.

Problem

Every analyze run regenerates the full GitNexus section in CLAUDE.md/AGENTS.md with the verbose template (tool descriptions, usage instructions, risk levels, etc.). Teams that maintain a lean custom format have to re-edit the file after every reindex.

Solution

• If <!-- gitnexus:keep --> is present inside the GitNexus block, only the stats line is updated (e.g., "Indexed as repo (N symbols, N relationships, N execution flows)")
• If no keep marker is present, behavior is unchanged — full template replacement
• Broadened stats-line regex to match both "Indexed as" and "indexed by GitNexus as" formats
• If keep marker is present but no stats line is found, the section is preserved as-is

Files changed

• gitnexus/src/cli/ai-context.ts — keep marker detection + stats-only update logic
• gitnexus/test/unit/ai-context.test.ts — unit tests for keep preservation and no-keep replacement

Test plan

• Unit tests for keep marker preservation
• Unit tests for no-keep full replacement
• Verified on 10+ repos in the dp-web4 collective with custom CLAUDE.md formats

🤖 Generated with Claude Code

[vercel]

Someone is attempting to deploy a commit to the NexusCore Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

CI Report

❌ Some checks failed

Pipeline Status

Stage	Status	Details
❌ Typecheck	failure	tsc --noEmit
✅ Tests	success	unit tests, 3 platforms
✅ E2E	success	gitnexus-web changes only

Test Results

Tests	Passed	Failed	Skipped	Duration
4801	4755	0	46	183s

✅ All 4755 tests passed

46 test(s) skipped — expand for details

• buildTypeEnv > known limitations (documented skip tests) > Ruby block parameter: users.each { |user| } — closure param inference, different feature
• Swift constructor-inferred type resolution > detects User and Repo classes, both with save methods
• Swift constructor-inferred type resolution > resolves user.save() to Models/User.swift via constructor-inferred type
• Swift constructor-inferred type resolution > resolves repo.save() to Models/Repo.swift via constructor-inferred type
• Swift constructor-inferred type resolution > emits exactly 2 save() CALLS edges (one per receiver type)
• Swift self resolution > detects User and Repo classes, each with a save function
• Swift self resolution > resolves self.save() inside User.process to User.save, not Repo.save
• Swift parent resolution > detects BaseModel and User classes plus Serializable protocol
• Swift parent resolution > emits EXTENDS edge: User → BaseModel
• Swift parent resolution > emits IMPLEMENTS edge: User → Serializable (protocol conformance)
• Swift cross-file User.init() inference > resolves user.save() via User.init(name:) inference
• Swift cross-file User.init() inference > resolves user.greet() via User.init(name:) inference
• Swift return type inference > detects User class and getUser function
• Swift return type inference > detects save function on User (Swift class methods are Function nodes)
• Swift return type inference > resolves user.save() to User#save via return type of getUser() -> User
• Swift return-type inference via function return type > resolves user.save() to User#save via return type of getUser()
• Swift return-type inference via function return type > user.save() does NOT resolve to Repo#save
• Swift return-type inference via function return type > resolves repo.save() to Repo#save via return type of getRepo()
• Swift implicit imports (cross-file visibility) > detects UserService class in Models.swift
• Swift implicit imports (cross-file visibility) > resolves UserService() constructor call across files (no explicit import)
• Swift implicit imports (cross-file visibility) > resolves service.fetchUser() member call across files
• Swift implicit imports (cross-file visibility) > creates IMPORTS edges between files in the same module
• Swift extension deduplication > detects Product class
• Swift extension deduplication > resolves Product() constructor despite extension creating duplicate class node
• Swift extension deduplication > resolves product.save() to Product.swift (primary definition)
• Swift constructor call fallback (no new keyword) > resolves OCRService() as constructor call across files
• Swift constructor call fallback (no new keyword) > resolves ocr.recognize() member call via constructor-inferred type
• Swift export visibility (internal vs private) > resolves PublicService() constructor across files
• Swift export visibility (internal vs private) > resolves internalHelper() across files (internal = module-scoped)
• Swift if let / guard let binding resolution > detects User and Repo classes
• Swift if let / guard let binding resolution > resolves user.save() inside if-let to User#save
• Swift if let / guard let binding resolution > resolves repo.save() inside guard-let to Repo#save
• Swift if let / guard let binding resolution > user.save() in if-let does NOT resolve to Repo#save
• Swift await / try expression unwrapping > resolves user.save() via await fetchUser() return type
• Swift await / try expression unwrapping > resolves repo.save() via try parseRepo() return type
• Swift await / try expression unwrapping > detects fetchUser and parseRepo as functions
• Swift for-in loop element type inference > detects User and Repo classes
• Swift for-in loop element type inference > creates implicit import edges between files
• Swift field-type resolution > detects classes and their properties
• Swift field-type resolution > emits HAS_PROPERTY edges from class to field
• Swift field-type resolution > resolves field-chain call user.address.save() → Address#save
• Swift field-type resolution > emits ACCESSES edges for field reads in chains
• Swift field-type resolution > populates field metadata (visibility, declaredType) on Property nodes
• Swift call-result binding > resolves call-result-bound method call user.save() → User#save
• Swift call-result binding > getUser() is present as a defined function
• Swift call-result binding > emits processUser -> getUser CALLS edge for let-assigned free function call

Code Coverage

Tests

Metric	Coverage	Covered	Base	Delta	Status
Statements	70.76%	13034/18418	70.75%	📈 +0.0	🟢 ██████████████░░░░░░
Branches	60.05%	8612/14340	60.06%	📉 -0.0	🔴 ████████████░░░░░░░░
Functions	75.51%	1144/1515	75.51%	＝ 0.0	🟢 ███████████████░░░░░
Lines	72.94%	11856/16253	72.93%	📈 +0.0	🟢 ██████████████░░░░░░

---

_{📋 View full run · Generated by CI}

[magyargergo]

Please submit a new PR if this is still relevant

[dp-web4]

@magyargergo resubmitted as 1508