* Initial plan
* fix: use recursive-sort replacer in hashToolCall to preserve nested properties
The array replacer in JSON.stringify acted as a property-name whitelist at
every nesting level, stripping all nested object properties and causing
structurally different tool calls to produce identical hashes. This led to
false-positive loop detection for tools with nested/array arguments like
ask_user_questions, plan_clarify, browser_batch, etc.
Replace with a function replacer that recursively sorts object keys while
preserving array order and primitive values.
Co-authored-by: glittercowboy <186001655+glittercowboy@users.noreply.github.com>
Agent-Logs-Url: https://github.com/gsd-build/gsd-2/sessions/c10384bc-a2f9-46b8-8380-43ea451ed39d
* fix: add missing codeFilesChanged to mergeMilestoneToMain mock in journal-integration test
Pre-existing typecheck failure: the mock was missing the codeFilesChanged
property added to the mergeMilestoneToMain return type.
Co-authored-by: glittercowboy <186001655+glittercowboy@users.noreply.github.com>
Agent-Logs-Url: https://github.com/gsd-build/gsd-2/sessions/debb019f-2fc8-4c76-b809-ecfe48993eff
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: glittercowboy <186001655+glittercowboy@users.noreply.github.com>
Path traversal guards used hardcoded "/" separator which fails on Windows
where resolve() produces backslash paths. Test assertions also used
forward-slash path fragments.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
QA23-1: Resolve custom Gradle version-catalog accessor names by
matching settings.gradle(.kts) create(name) declarations to catalog
filenames by basename, so ./gradle/foo.versions.toml and similar valid
path spellings are recognized.
QA23-2: Exclude Poetry group dependencies from FastAPI framework
classification to avoid dev/test-only FastAPI deps implying application
usage.
Add regression tests for:
- settings-defined catalog accessors that differ from TOML basename
- Poetry group FastAPI false positives
QA22-1: Support deeper pip-tools layouts under requirements/**
(e.g. requirements/dev/base.in) for Python/FastAPI detection and
requirements.txt marker normalization.
QA22-2: Resolve Gradle version-catalog accessor names from
settings.gradle(.kts) create(name) { from(files(...versions.toml)) }
blocks instead of assuming the accessor must equal the TOML basename.
Also treat settings.gradle(.kts) like other Gradle files for comment
stripping during catalog parsing.
QA21-1: Recognize pip-tools style requirement manifests, including
requirements.in, requirements-dev.in, and files under requirements/*.in
or requirements/*.txt, for Python/FastAPI detection and nested marker
normalization.
QA21-2: Generalize Spring Boot version-catalog detection beyond the
default libs accessor by supporting any *.versions.toml catalog name and
matching its corresponding accessor in build.gradle(.kts).
Also fix the root-level requirements/base.in path matcher and add
regression tests for custom catalog accessors and pip-tools layouts.
QA20-1: Make Spring Boot bundle detection order-independent by first
collecting library aliases across version catalogs and then resolving
bundle aliases against that complete set.
QA20-2: Recognize common split Python requirements layouts
(requirements/base.txt, requirements-dev.txt, etc.) as requirements
sources for both Python/FastAPI detection and nested marker
normalization.
Also repair the detector helper block after the prior patch splice and
keep the full regression suite green.
QA19-1: In pyproject dependency parsing, treat Poetry/table-form keys
as dependency names and only scan quoted requirement specs on
[project] dependencies / optional-dependency array lines. Prevents
extras like extras = ["fastapi"] from emitting dep:fastapi.
QA19-2: Support legacy Gradle Spring Boot declaration styles via
apply plugin: 'org.springframework.boot' and apply(plugin = ...).
QA19-3: Scope Maven Spring Boot detection to org.springframework.boot
groupId instead of any artifactId that happens to start with
spring-boot.
Add regression tests for:
- Poetry dependency table extras mentioning fastapi
- legacy apply plugin Spring Boot detection
- Maven artifactId-only spring-boot false positive
QA18-1: Replace token-level FastAPI matching with package-name-aware
parsing for requirements.txt and pyproject dependency sections so extras
like my-sdk[fastapi] and unrelated fastapi tokens do not emit
dep:fastapi.
QA18-2: Scope direct Spring Boot detection to actual plugin/dependency
declarations instead of arbitrary spring-boot text, and fix Kotlin DSL
plugin syntax matching (id("org.springframework.boot")).
Add regression tests for:
- dependency extras mentioning fastapi
- build metadata mentioning spring-boot
- Kotlin DSL Spring Boot plugin detection
QA17-1: Support multiline arrays inside [project.optional-dependencies]
so FastAPI declared in multiline optional dependency groups is detected
correctly.
QA17-2: Extend Spring Boot version-catalog detection to bundle aliases
(libs.bundles.*) by resolving bundles back to library aliases that map
to org.springframework.boot artifacts.
Add regression tests for:
- multiline optional FastAPI dependencies
- Spring Boot bundle alias detection
QA16-1: In pyproject.toml, treat [project.optional-dependencies]
keys as extra names rather than dependency names by scanning only the
right-hand-side values. Prevents extras named 'fastapi' from emitting
dep:fastapi.
QA16-2: Support FastAPI direct-reference requirements using the @
operator (e.g. fastapi @ https://...).
QA16-3: Extend Spring Boot version-catalog detection to library aliases
(e.g. implementation(libs.backend.web) + module =
org.springframework.boot:spring-boot-starter-web), while keeping alias
correlation strict.
QA16-4: Use a neutral 'java/kotlin' language hint for nested Gradle
Spring Boot services, even when they use build.gradle.kts, to avoid
mislabeling Java codebases as Kotlin.
Add regression tests for optional-dependency extras, direct-reference
FastAPI, Spring Boot library aliases, and nested Gradle language hints.
QA15-1: Extend exact FastAPI dependency detection to support common
PEP 508 specifiers like ~= and !=.
QA15-2: Scope pyproject.toml FastAPI detection to actual dependency
sections ([project] dependencies array, [project.optional-dependencies],
[tool.poetry.dependencies], and [tool.poetry.group.*.dependencies]) so
metadata-only mentions do not emit dep:fastapi.
QA15-3: Remove spring.boot alias-name matching from direct Spring Boot
detection. Direct matches now require org.springframework.boot or
spring-boot(-starter) strings; alias-based detection only succeeds via
alias usage + version-catalog id correlation.
QA15-4: When a nested Gradle Spring Boot service emits dep:spring-boot
and no language was otherwise detected, set primaryLanguage to
java/kotlin so onboarding no longer reports 'unknown project'.
Add regression tests for:
- FastAPI ~= operator
- pyproject metadata-only fastapi mention
- spring-like alias names without Spring Boot id
- nested Spring Boot language hint
QA14-1: Strip comments in libs.versions.toml indirectly by moving Spring
Boot version-catalog detection to alias correlation rather than raw
presence matching.
QA14-2: Require actual alias usage in build.gradle(.kts) plus matching
org.springframework.boot alias definition in libs.versions.toml before
emitting dep:spring-boot.
QA14-3: Tighten FastAPI detection to an exact dependency token with
valid package delimiters so fastapi-users / fastapi-cli alone do not
emit dep:fastapi.
Add stronger regression tests for:
- arbitrary Spring Boot alias correlation
- commented Spring Boot aliases
- unused Spring Boot aliases
- fastapi-* packages without fastapi itself
QA13-1: Strip inline trailing comments when scanning dependency/build
files so comment-only mentions of fastapi or spring-boot no longer emit
synthetic framework markers.
QA13-2: Detect Spring Boot in Gradle version-catalog alias setups by
including libs.versions.toml in the scan and matching spring.boot /
spring-boot alias patterns as well as org.springframework.boot.
Add regression tests for:
- FastAPI inline comments
- Android inline spring-boot comments
- Spring Boot version-catalog alias detection
QA12-1: Replace generic Gradle/POM matching for Java & Spring Boot
with a real framework marker () detected by scanning
pom.xml and Gradle files for Spring Boot plugins/dependencies. This
restores nested Gradle service detection without reintroducing Android
false positives.
QA12-2: Prevent standard Android projects (root build.gradle +
app/build.gradle) from matching the Spring Boot pack. Spring Boot now
requires the synthetic dependency marker, not generic build files.
QA12-3: Harden FastAPI detection:
- strip comments before matching
- scan each dependency file independently
- continue on per-file read errors instead of failing the whole scan
Also add regression tests for comment-only FastAPI mentions, nested
Spring Boot Gradle services, Android non-Spring Gradle projects, and
Spring Boot pack matching via dep:spring-boot.
QA11-1: Expand recursive-scan ignore set to skip common heavyweight
folders (.venv, venv, Pods, bin, obj, .gradle, DerivedData, out)
so the bounded scan is far less likely to exhaust its budget before
reaching relevant nested project files.
QA11-2: Remove the arbitrary 10-file cap from FastAPI dependency reads.
All discovered requirements.txt / pyproject.toml files within the bounded
scan are now checked, eliminating traversal-order dependence in
multi-service repos.
QA11-3: Normalize safe nested project markers from the recursive scan
back into PROJECT_FILES markers (e.g. nested next.config.ts, manage.py,
requirements.txt, prisma/schema.prisma, app/build.gradle) while keeping
noisy root-only markers like package.json and generic build.gradle
root-only. Add regression tests for these nested layouts and Android
root-only exclusion behavior.
QA8-1: Add case-insensitivity test for FastAPI detection using PyPI
canonical name 'FastAPI' (mixed case) in pyproject.toml.
QA8-2: False positive — comment matching is acceptable tradeoff;
mentions of 'fastapi' in requirements comments almost always correlate
with actual FastAPI usage or intent.
QA8-3: Empty catch block is trivially correct; skipping test for it.
Replace the lazy 'no brownfield detection' approach with proper
dependency-based detection. Scan requirements.txt and pyproject.toml
for the 'fastapi' package name (case-insensitive word-boundary match)
using the existing readBounded() utility (64KB cap).
Adds 'dep:fastapi' synthetic marker to detectedFiles when found,
which the FastAPI skill pack matches via matchFiles: ['dep:fastapi'].
This ensures only actual FastAPI projects get the pack recommended,
not all Python projects.
Tests: 3 new detection tests (requirements.txt, pyproject.toml,
negative Django case) + 1 new catalog test (dep:fastapi matching).
Total: 50 detection + 17 catalog + 5 activation + 12 smoke = 84.
QA6-1: Add 16 matchPacksForProject unit tests covering language match,
file match, Xcode platform match, matchAlways, and isolation checks
(FastAPI not in generic Python, Spring Boot not via language alone,
Unity/Godot don't cross-contaminate).
QA6-2: Remove FastAPI from brownfield auto-detection entirely — no
matchFiles or matchLanguages. Available via greenfield stack selection
or manual install only, since no FastAPI-specific file marker exists
on disk.
QA6-3: Remove matchLanguages from Java & Spring Boot pack so it only
triggers via matchFiles (pom.xml, build.gradle*). Prevents Android
projects from getting Spring Boot recommended via language match.
QA6-4: False positive — F# gets 'csharp' label cosmetically but the
.NET packs are correct for F# developers.
QA5-1: Remove matchLanguages from FastAPI pack so it only triggers via
file-based detection (matchFiles), not for all Python projects. Aligns
with Django precedent of framework-specific file matching.
QA5-2: Add requirements.txt to pytest verification command check so
requirements.txt-only Python projects get pytest suggested.
QA5-3: Add FastAPI greenfield stack entry (packs: FastAPI + Python +
Python Advanced) for parity with Django.
QA5-4: False positive — Vue src/ scanning is non-recursive by design;
all standard Vue scaffolds place App.vue directly in src/.
QA5-5: Add 11 new detection tests covering Vue .vue scanning, Vue CLI
config, requirements.txt Python detection, Android app/build.gradle,
Unity, Godot, Airflow, Kubernetes Helm, Blockchain Hardhat, CI/CD
.github/workflows, and Tailwind config. Test count: 36 → 47.
QA4-1: Split Game Development into separate Unity and Godot packs to
avoid cross-contamination between engines.
QA4-2: Add requirements.txt to Python base pack matchFiles so Python
Advanced doesn't trigger without the base pack.
QA4-3: Add Prisma to fullstack-js greenfield stack to differentiate
it from react-web.
QA4-4: Remove Spring Boot from Android greenfield stack — server-side
Java framework is irrelevant for Android development.
QA4-5: Extract FastAPI into its own pack (consistent with Django being
separate) instead of bundling in Python Advanced.
QA4-6: Add airflow.cfg to PROJECT_FILES and Data Engineering matchFiles
so Airflow-only projects also trigger data engineering skills.
QA4-7: Add Tailwind CSS to react-web, fullstack-js, nextjs, and
svelte greenfield stacks.
QA4-8: Add Unity and Godot as separate greenfield stack options.
QA4-9: Fix Vue.js detection for non-Nuxt projects by adding .vue
file extension scanning (scans src/ for *.vue files), vue.config.*
to PROJECT_FILES, and *.vue synthetic marker to Vue.js pack matchFiles.
QA4-10: Add app/build.gradle and app/build.gradle.kts to LANGUAGE_MAP
for Android project language detection.
- Fix Windows fd leak: close markerFd before unlinkSync in catch block
- Increase pbxproj read limit from 256KB to 1MB (SDKROOT appears after
file references/build phases in large projects)
- Fix matchPacksForProject docstring: returns catalog order, not sorted
- Add legacy dir to skill telemetry (captureAvailableSkills, detectStaleSkills)
so pre-migration skills appear in health/telemetry reports
Greenfield projects (empty directories) no longer ask users to pick a tech
stack during init. Non-technical users may not know their architecture yet.
Instead, only essential packs (find-skills, skill-creator, agent-browser,
document handling) are installed. Stack-specific skills auto-detect later
via brownfield detection once the LLM creates project files.
GREENFIELD_STACKS retained as a reference for programmatic use by the LLM
and the /gsd skills command.
- Add Firebase, Azure, and AWS skill packs to curated catalog
- Add cloud config files (firebase.json, cdk.json, samconfig.toml, serverless.yml)
and React Native markers (metro.config.js/ts, react-native.config.js) to detection
- Fix React Native detection to use matchFiles instead of broad language match
- Add matchAlways flag for essential packs so they are offered to all projects
- Add Firebase/AWS/Azure to greenfield tech stack wizard
- Improve Xcode detection: scan ios/macos/app subdirs, use bounded fd read,
set primaryLanguage=swift when xcodeproj found, handle SDKROOT=auto via
SUPPORTED_PLATFORMS fallback
- Fix migration: handle symlinked skill dirs, use atomic wx flag for race safety
Catalog changes:
- Added: find-skills (#1 on skills.sh, 657K installs), shadcn/ui (#5,
130K), skill-creator (#26, 98K), agent-browser (#23, 120K)
- Removed from React pack: web-design-guidelines (thin wrapper that
just fetches an external URL; redundant with the Vercel ecosystem
version and userinterface-wiki)
- The old bundled skills (18 total, 11 web-frontend-focused) are no
longer force-synced. The catalog now points to the better ecosystem
versions from Vercel, Anthropic, and shadcn.
Reasoning: The original bundled skills were heavily web-frontend biased
with significant overlap (3 UI polish skills, 4 web audit skills). The
catalog should surface the highest-quality ecosystem skills rather than
force-installing duplicative bundled ones.
Existing GSD users have skills in ~/.gsd/agent/skills/ that would
silently vanish after the directory switch. This adds:
1. One-time migration in initResources() — copies skill directories
from ~/.gsd/agent/skills/ to ~/.agents/skills/ (collision-safe,
writes .migrated-to-agents marker so it runs at most once).
2. Legacy fallback reads in loadSkills() and getSkillSearchDirs() —
the old directory is scanned as a low-priority fallback so skills
work immediately, even before the migration runs on next restart.
The old directory is NOT deleted — users can safely downgrade to a
pre-migration GSD version without losing skills.
Replace boolean hasXcodeProject with xcodePlatforms array that reads
SDKROOT values from *.xcodeproj/project.pbxproj files. iOS skill packs
now only match when SDKROOT=iphoneos, so macOS / watchOS / visionOS /
tvOS Xcode projects won't get iOS-specific skills.
Also splits the monolithic "Swift / iOS" pack into 8 granular bundles
matching dpearson2699/swift-ios-skills plugin structure:
- SwiftUI + Swift Core (any Swift project)
- iOS App Frameworks, Data Frameworks, AI & ML, Engineering,
Hardware, Platform (iphoneos projects only)
Adds batched installation to minimize npx invocations when multiple
packs share the same repo.
Stop force-syncing bundled skills to ~/.gsd/agent/skills/ on every launch.
Instead, use ~/.agents/skills/ (the industry-standard skills.sh directory)
as the primary global skills location, and .agents/skills/ for project-local
skills.
Changes:
- loadSkills() now scans ~/.agents/skills/ (global) and .agents/skills/ (project)
instead of ~/.gsd/agent/skills/ and .gsd/skills/
- initResources() no longer syncs src/resources/skills/ → ~/.gsd/agent/skills/
- skill-discovery, skill-telemetry, skill-health, preferences-skills all updated
to use the ecosystem directory
- New skill-catalog.ts: curated skill packs mapped to tech stacks, with
brownfield auto-detection and greenfield tech stack selection
- Init wizard gains a skill installation step that presents relevant packs
and installs via `npx skills add`
- Export ECOSYSTEM_SKILLS_DIR and ECOSYSTEM_PROJECT_SKILLS_DIR from pi-coding-agent
Fixes#2004
The stale dependency check compared package-lock.json mtime against the
node_modules directory mtime. Directory mtime only updates when entries
are added or removed — not when files inside are updated. This caused a
permanent false-positive warning after `npm install` when dependencies
were already up to date, because npm rewrites the lockfile (advancing
its mtime) without adding/removing directory entries.
Compare against package manager marker files instead:
- npm: node_modules/.package-lock.json
- yarn: node_modules/.yarn-integrity
- pnpm: node_modules/.modules.yaml
Falls back to directory mtime when no marker file exists.
Fixes#1974
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The orphaned_auto_worktree fix skipped removal when process.cwd() was
inside the worktree, creating a deadlock where the doctor repeatedly
detected the orphan but never cleaned it up. Now chdir to basePath
first, matching the existing pattern in removeWorktree().
Fixes#1946
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The regex in extractSlicesSection matched Slices, Slice Overview, Slice Table,
Slice Summary, and Slice Status but not Slice Roadmap. When a roadmap used the
'## Slice Roadmap' heading, the section extractor returned empty, causing the
parser to fall through to prose headers which lack checkbox state -- marking all
slices as incomplete and trapping auto-mode in a dispatch loop.
Add 'Roadmap' to the alternation and a regression test that verifies checkbox
slices under the '## Slice Roadmap' heading are parsed with correct done state.
Fixes#1940
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* test: add assertion messages to fix Assertion Roulette in GSD tests
Add descriptive messages to multi-assertion tests where a bare failure
output ("expected true, got false") wouldn't identify which assertion
broke. Affected tests: auto-secrets-gate, search-tavily, search-provider-
command, tavily-helpers.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test: fix Eager Test smell in captures and worktree-manager tests
- Split captures: loadPendingCaptures test — extracted loadAllCaptures
assertion into its own focused test
- Refactor worktree-manager: replace monolithic main() script with 11
isolated test() calls, each with its own repo setup via helpers
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test: add assertion messages to remaining test files
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test: fix contract test gate, dynamic roots, and shared fetch helpers
- Fix reject-notice sub-test gated on outcome.kind (actual) instead of
expectedKind (map value) in web-command-parity-contract.test.ts
- Restore dynamic loop over registered non-gsd passthrough roots with
an explicit count assertion so new registrations fail loudly
- Extract normalizeHeaders/parseJsonBody to src/tests/fetch-test-helpers.ts
and import in both search-tavily and llm-context-tavily tests
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Use realpathSync.native() on Windows in canonicalizeExistingPath to resolve
8.3 short names (RUNNER~1 → runneradmin). Fixes isInheritedRepo path
comparison failures on Windows CI.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The roadmap-done condition checked whether the missing-summary issue was
detected in the issues array, but at fixLevel="task" the summary is
detected and never fixed (deferred via COMPLETION_TRANSITION_CODES).
This caused the roadmap checkbox to be marked without the summary on
disk, making deriveState() skip the summarizing phase and hard-stop at
validating-milestone.
Replace the issues.some() fallback with an existsSync re-check so the
roadmap is only marked when the summary actually exists — either
pre-existing or created earlier in the same doctor run.
Fixes#1910
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
mergeMilestoneToMain now detects when the squash-merge commit contains
only .gsd/ metadata files and no actual code changes. The worktree
resolver surfaces a clear warning so users know the milestone summary
may describe planned work that was never implemented.
The complete-milestone prompt now requires the LLM to verify code
changes exist on the branch before declaring verification passed.
Fixes#1906
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Resolve Windows 8.3 short paths (RUNNER~1 → runneradmin) via realpathSync.native()
and use shell mode for .bat/.cmd files in worktree post-create hooks. Fixes
pre-existing windows-portability CI failure.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
