Resolve behavior when configuration discovery finds no file
This commit is contained in:
@@ -47,8 +47,24 @@ higher-priority override layers. Missing optional imports may be absent;
|
||||
operators use `required: true` for essential inputs. Invalid declarations,
|
||||
unreadable selected files, and composition conflicts retain native errors.
|
||||
|
||||
Behavior when automatic discovery finds no file remains a separate open decision
|
||||
below. This does not reopen the selected search order or import support.
|
||||
### No Configuration File Found — Resolved
|
||||
|
||||
Use ConfigKit's optional-search behavior when automatic discovery finds no file:
|
||||
continue with embedded defaults, underlays, and explicit CLI settings, then
|
||||
validate what the requested command needs. Require sufficient configuration for
|
||||
the operation, not the existence of a main configuration file.
|
||||
|
||||
Resource inspection can work without a main file. Processing can run when its
|
||||
required selections and inputs are otherwise supplied through supported
|
||||
mechanisms. Report missing command-specific settings clearly; do not invent an
|
||||
implicit model or profile selection to make incomplete execution settings pass.
|
||||
Inspection must accurately show that no main file was selected.
|
||||
|
||||
Define filesystem context explicitly where overlays or relative resource inputs
|
||||
need it; do not infer a base from unsuccessful search candidates. Preserve the
|
||||
native absent-main lifecycle instead of manufacturing a placeholder file or
|
||||
source record. Explicit-file errors and failures loading a selected discovered
|
||||
file remain terminal.
|
||||
|
||||
### Migration Work
|
||||
|
||||
@@ -100,7 +116,10 @@ suite at the coordinated migration boundary.
|
||||
Check explicit-file selection without fallback, native working/user/system
|
||||
search precedence, and terminal errors for a selected invalid file. Verify
|
||||
optional and required imports and peer-composition errors through Audita's
|
||||
integration. Cover discovery exhaustion after its behavior is selected below.
|
||||
integration. Verify that discovery exhaustion permits inspection and sufficiently
|
||||
configured processing, while incomplete processing reports its missing inputs.
|
||||
Cover absent-main provenance and filesystem context for selected overlays or
|
||||
relative resources without weakening explicit-file error behavior.
|
||||
|
||||
The earlier passing configuration suite is useful baseline evidence, not proof
|
||||
that operators see unchanged semantics. Native semantics and clear migration are
|
||||
@@ -114,26 +133,6 @@ requirement and the smallest integration boundary that satisfies it.
|
||||
|
||||
## Open Decisions
|
||||
|
||||
### No Configuration File Found
|
||||
|
||||
**Recommendation:** use ConfigKit's optional-search behavior: continue with
|
||||
embedded defaults, underlays, and explicit CLI settings, then validate what the
|
||||
requested command needs. A missing main file alone should not prevent resource
|
||||
inspection or execution whose required inputs are otherwise supplied. Do not
|
||||
invent an implicit model/profile choice to make incomplete execution settings
|
||||
pass validation. Define filesystem context explicitly where overlays or relative
|
||||
resource inputs need it; do not infer a base from unsuccessful search candidates.
|
||||
|
||||
This follows the native absent-main lifecycle and supports lightweight command
|
||||
invocations. It requires clear errors for missing command-specific inputs and
|
||||
inspection that accurately shows that no main file was selected.
|
||||
|
||||
**Alternative:** require a discovered configuration file for configuration-dependent
|
||||
commands, while keeping help/version independent. This gives deployments a
|
||||
mandatory configuration anchor, but rejects otherwise sufficient defaults and
|
||||
CLI settings and adds a requirement without an identified domain need. Explicit
|
||||
file errors remain terminal under either choice.
|
||||
|
||||
### Application Schema Version
|
||||
|
||||
**Recommendation:** design the application schema around the target ownership
|
||||
|
||||
Reference in New Issue
Block a user