Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

Compose Tasks and Reuse Scripts

A reusable companion becomes more valuable when another task can consume its properties locally. The agent should not need to read a full Git report again just to combine repository cleanliness with a commit identifier. QuietCli supports this composition through ordinary data values and an enclosing task that records intermediate execution results.

The Invoke-RepositoryDecision.ps1 (ouvre dans une nouvelle fenêtre) example reuses the supplied Git overview companion. It launches that companion in a separate PowerShell process, parses the returned envelope locally, records the inner result, obtains HEAD through another native Git command, and emits a small final projection. The example deliberately makes the boundary between native process success and domain operation success visible.

Run a second use of the companion

From an extracted module or source checkout:

$moduleRoot = 'C:/tools/QuietCli'
& (Join-Path $moduleRoot 'examples/Invoke-RepositoryDecision.ps1') `
    -Repository 'C:/code/my-project' `
    -QuietCliRoot $moduleRoot -MaxOutputBytes 2048

The default runtime path points to the companion's module directory. A different checkout can be supplied explicitly. The script requires a repository with a resolvable HEAD; an unborn repository is outside this composition's successful domain contract, even though the simpler overview companion can still provide some observations about it.

The final data includes branch, commit identifier, changed and untracked entry counts, and NeedsReview. That Boolean only means that the overview found entries requiring attention. It is not a release authorization or a complete judgment about the changes. Its name and scope should keep that distinction understandable to readers.

A process can succeed while its result fails

A companion script returns a QuietCli envelope as JSON. Successfully launching its interpreter and decoding that JSON does not guarantee that the operation described by the envelope succeeded. The inner result might contain Outcome: Failed or Timeout while the interpreter itself exits normally.

The composition therefore records two different facts. First, Invoke-QuietCli reports whether the companion process and JSON analysis succeeded. Second, Invoke-QuietStep records the parsed inner envelope as a domain execution result. The task checks the inner outcome, its analysis status and its AnswerComplete property before using overview fields.

This pattern avoids a subtle failure mode: collapsing every successfully parsed JSON response into successful business execution. It is useful whenever one reusable program returns a structured result describing another operation. The outer orchestration needs to preserve the semantics of that result, not merely its serialization.

Register consumed results

Inside a QuietCli task, use Invoke-QuietStep for every result consumed locally. Assigning a result to a variable alone does not notify the task aggregator. The step wrapper validates the common envelope and records its status before returning it to local code.

The essential pattern is:

Invoke-QuietTask -MaxOutputBytes 2048 -AsJson {
    $inspection = Invoke-QuietStep inspect {
        New-QuietResult -Data @{ Count=3 } `
            -Execution @{ AnalysisComplete=$true }
    }
    if ($inspection.Outcome -ne 'Success') { return }
    [pscustomobject]@{ Count=$inspection.Data.Count }
}

This small block illustrates composition syntax using already calculated data. The actual repository example executes native tools and validates their formats. In both cases, the task body emits the final domain projection; it does not stream every intermediate envelope to the model.

The verification runner also consumes a deliberately failed step and then emits a projection containing an unknown count. The final task must remain failed, and that count must remain null. This checks the behavior that matters when local control flow would otherwise hide an error.

Budget the whole task

Several individually small responses can still create a large conversation when the agent reads them all. Invoke-QuietTask provides one final boundary. Here the final document must fit within 2,048 UTF-8 bytes, including execution counters and selected diagnostics.

That budget is not a guarantee that every intermediate object remains available unchanged. Intermediate results are bounded too, and the task records their truncation. A required domain value lost earlier cannot be reconstructed by simply selecting it in the final projection. Check the relevant result's fields and omission status before relying on it.

The inspected runtime limits selected issues and projection items. Detailed diagnostics can therefore be omitted while failure counters remain useful. Design an explicit response for follow-up investigation instead of expecting the common envelope to archive the entire run. The report in this series is a separate verification artifact with its own purpose.

Keep reuse honest

The composition executes observations sequentially. It explicitly states that they are not an atomic snapshot. It also starts a separate PowerShell process to demonstrate script reuse clearly; that choice has startup overhead. No measured advantage over an in-process companion or another tool is asserted.

Saving a companion amortizes authoring effort only if it is reused and maintained. A changed CLI format, a new counting scope or a stronger consistency requirement can require revisiting the script and its checks. Reuse means keeping a verified capability, including its limitations, rather than preserving old code indefinitely because it once produced a short answer.

Previous: Streaming Jobs · Series overview · Next: QuietCli, OPumper and RTK Together

⬇ Download