# Walking Skeleton: Rigor Global Configuration

## Skeleton Identification

Three walking skeletons cover the three cascade levels, each delivering observable user value.

### WS-1: Global rigor applies in unconfigured project

**User goal**: Developer's global rigor preference is active automatically when opening a project with no rigor configured.

**Observable outcome**: `rigor_profile` returns "custom" and `rigor_agent_model` returns "opus" when project has no rigor key but global config has a custom profile.

**Stakeholder demo**: "Ale opens client-C, which has no rigor set. His global custom/opus preference is active immediately -- he never ran /nw:rigor in this project."

**Driving port**: `DESConfig(config_path=..., global_config_path=...)`

### WS-2: Project rigor overrides global

**User goal**: Developer can override their global preference in a specific project.

**Observable outcome**: `rigor_profile` returns "lean" and `rigor_agent_model` returns "haiku" when project has lean rigor, even though global has custom/opus.

**Stakeholder demo**: "Ale's nwave-ai repo uses lean rigor for documentation changes. His global opus preference is ignored here."

**Driving port**: `DESConfig(config_path=..., global_config_path=...)`

### WS-3: New user gets standard defaults

**User goal**: New user without any configuration gets sensible defaults.

**Observable outcome**: All `rigor_*` properties return standard defaults (sonnet, haiku, 5-phase, etc.) when neither project nor global config has rigor.

**Stakeholder demo**: "Tomasz installs nWave for the first time. Without any configuration, he gets the recommended standard profile."

**Driving port**: `DESConfig(config_path=..., global_config_path=...)`

## Implementation Sequence

The walking skeletons should be enabled in this order during DELIVER:

1. **WS-3** (defaults) -- simplest path, no global config file needed. Validates that the new `global_config_path` parameter does not break existing behavior.
2. **WS-1** (global cascade) -- adds global config reading. Validates the cascade fallthrough.
3. **WS-2** (project override) -- validates short-circuit when project has rigor.

## Litmus Test Results

| Criterion | WS-1 | WS-2 | WS-3 |
|-----------|------|------|------|
| Title describes user goal? | Yes | Yes | Yes |
| Given/When describe user context? | Yes | Yes | Yes |
| Then describe user observations? | Yes | Yes | Yes |
| Non-technical stakeholder confirms? | Yes | Yes | Yes |
