Extend config.json reference with complete field documentation

[davesienkowski]

Pre-submission checklist

• I have confirmed this improves existing behavior -- it does not add a new command, workflow, or concept
• I have searched existing issues and this enhancement has not already been proposed
• I have read CONTRIBUTING.md and understand I must wait for approved-enhancement before writing any code
• I can clearly describe the concrete benefit -- not just "it would be nicer"

What existing feature or behavior does this improve?

The configuration documentation in get-shit-done/references/planning-config.md and the /gsd-settings command.

Current behavior

GSD's planning-config.md documents some config.json fields but is not a complete reference. Fields like model_profile, parallelization, and verifier are documented, but the full set of allowed values, defaults, validation rules, and interactions between fields is not captured in one place. A solo developer configuring their project must experiment or read source code (config.cjs) to discover available options.

Proposed behavior

Extend planning-config.md (or create a comprehensive config-reference.md if the existing file's scope is too narrow) to include:

• Complete field table: Every supported config.json field with type, allowed values, default, and description
• Validation rules: What happens when invalid values are provided (error vs fallback)
• Field interactions: How fields affect each other (e.g., depth affects research thoroughness AND verification detail)
• Example configurations: Common setups (solo dev with 1M context, budget-conscious developer, CI/CD pipeline)

Reason and benefit

Why the current behavior is a problem:
A solo developer cannot discover all configuration options without reading source code. The /gsd-settings command offers some options interactively but doesn't expose advanced fields. Undocumented fields lead to either unused features or misconfiguration.

Concrete benefit:
One document answers "what can I configure?" completely. Developers can optimize their setup without reading source code. New config fields added in future releases have a clear place to be documented.

Scope of changes

Files modified:

• get-shit-done/references/planning-config.md -- extend with complete field reference, validation rules, interactions, and examples

No new files needed if the existing document can be expanded. No new dependencies.

Breaking changes

None. Documentation-only change.

Alternatives considered

1. Auto-generate config docs from schema -- Would require a formal JSON schema (GSD validates in code, not via schema file). Good long-term goal but the manual reference is needed now.
2. Document in README only -- README should link to the reference, not contain it. Config details belong in the references directory where agents can load them.

Area affected

Documentation

[trek-e]

✅ Approved as enhancement.

Straightforward documentation improvement. Config discoverability without reading source is a real quality-of-life win.

Implementation notes:

• Extend the existing planning-config.md rather than creating a new file — keep the single source of truth
• The field table should be generated by reading CONFIG_DEFAULTS and validation logic in config.cjs — ensure it stays accurate
• Include the default value for every field so developers know what they get out of the box
• Example configurations section is high-value — make them copy-pasteable

@davesienkowski — labeled approved-enhancement. You're clear to implement.