The Options Model
How a fusion request is composed from scoped option records and the validation rules that gate it.
A fusion is described by a single request object, not a flat bag of settings. That object groups options by the stage they belong to, carries at most one optional scoping mode, and is built from CLI flags or MCP parameters merged with config-file values. Before any stage runs, a validator checks the request against a fixed set of rules. This page documents the request shape, the defaults of each option group, and the validation rules.
This page is for engineers reading or constructing requests and for maintainers who need the authoritative default values and constraints.
Architectural Rationale
A single monolithic options type forces every consumer to depend on every setting and makes it unclear which option affects which stage. The request instead composes one record per stage, so collection, reduction, and emission each own their settings, and scoping is expressed as optional records that are present only when used. Building the request in one place (the request builder) and validating it in one place (the validator) means precedence and constraints are decided once, not scattered across call sites.
The Fusion Request
A fusion request is composed of three required option groups, up to one optional scoping group, and a few run-level flags.
| Member | Type | Default | Meaning |
|---|---|---|---|
| Collection | CollectionOptions | required | File discovery and filtering |
| Reduction | ReductionOptions | required | Content reduction settings |
| Emission | EmissionOptions | required | Output format and token budget |
| Focus | FocusOptions | none | Focus scoping, when present |
| Changes | ChangeOptions | none | Git-change scoping, when present |
| Query | QueryOptions | none | Query scoping, when present |
| InMemory | bool | false | Return content in memory instead of writing to disk |
| Parallelism | int | 0 | Degree of parallelism; 0 means processor count |
| UseReductionCache | bool | true | Use the on-disk reduction cache |
| ClearReductionCache | bool | false | Clear the reduction cache before the run |
At most one of Focus, Changes, and Query may be present; the validator rejects any combination of two or more.
Building And Merging
The request builder constructs a request from CLI flags or MCP tool parameters and merges them with values from a config file. Precedence is fixed: an explicit CLI flag overrides a config-file value, and a config-file value overrides the built-in default. The defaults below are those built-in values, applied when neither a flag nor config supplies one.
Collection Options
| Option | Default | Meaning |
|---|---|---|
| Recursive | true | Scan subdirectories |
| IgnoreBinaryFiles | true | Skip binary files |
| ExcludeEmptyFiles | true | Skip zero-byte files |
| ExcludeAutoGenerated | true | Skip auto-generated files |
| RespectGitIgnore | true | Honor gitignore rules |
| MaxFileSizeKb | 0 | Maximum file size in kilobytes; 0 means no limit |
| ExcludeTestProjects | false | Exclude all test project directories |
The source directory, project template, and the resolved include and exclude lists are also part of this group.
Reduction Options
| Option | Default | Meaning |
|---|---|---|
| TrimContent | true | Trim leading and trailing whitespace per line |
| UseCondensing | true | Collapse blank lines |
| MinifyXmlFiles | true | Minify XML-based files |
| MinifyHtmlAndRazor | true | Minify HTML and Razor view files |
| EnableRedaction | true | Redact secrets before token counting |
| SkeletonMode | false | Emit C# structural skeleton only |
The C# structural removals (comments, usings, namespaces, regions, and aggressive compression) all default to false, so a default fusion preserves C# structure and removes only whitespace.
Emission Options
| Option | Default | Meaning |
|---|---|---|
| Format | Xml | Output serialization format |
| TokenizerModel | o200k_base | Tokenizer used for counting |
| SplitTokens | 800000 | Token threshold that starts a new output part |
| MaxTokens | none | Hard token limit across all parts; emission halts when exceeded |
| IncludeManifest | true | Prepend the manifest header |
| ShowTokenCount | true | Display the token count on completion |
| IncludeProvenance | false | Annotate each entry with its inclusion chain |
Validation Rules
The validator runs before any stage and reports every violation it finds. The rules are:
- The source directory must be specified and must exist.
- Focus, Changes, and Query are mutually exclusive; at most one may be present.
- When focus scoping is used, focus depth must be between 1 and 10.
- When query scoping is used, query depth must be between 1 and 10.
- When query scoping is used, the query text is required and the top-files count must be at least 1.
- The only-extensions restriction cannot combine with a project template, because only-extensions replaces template defaults entirely.
A request that violates any rule is rejected before collection begins.
What This Does Not Cover
This page documents the request shape, defaults, and validation. It does not map each option to its CLI flag or config key; see the Options Reference. It does not explain what the scoping options do once accepted; see Scoping Internals.
Next
See the Options Reference for the full flag and config mapping, The Fusion Pipeline for how each option group drives its stage, and Scoping Internals for the scoping algorithms.