You are implementing an English technical article series in an existing FrenchExDev static-site repository. Complete the content, executable examples, evidence and site integration. Inspect the actual sources before writing. Do not stop at an outline.

OBJECTIVE
Create content/blog/quietcli/ with an index and eight chapters under the title "QuietCli: useful answers beyond smaller CLI output". Explain this lifecycle: the agent defines its information need, verifies documentation, authors or reuses a companion script, executes the intended command, processes output locally, validates domain evidence, and reads one bounded result. Demonstrate at least the central benefits also developed by OPumper: local parsing and computation, useful structured data, explicit limits and failures, reuse, and a budget for the entire task. Explain practical complementarity with Rust Token Killer fairly.

INPUTS AND SOURCE PRIORITY
1. Applicable AGENTS.md instructions and the existing site's frontmatter, navigation and build configuration.
2. QuietCliRoot, supplied by the caller. Default on the author's machine: C:/code/FrenchExDev/FrenchExDev_i2/PoSh/FrenchExDev/FrenchExDev.QuietCli.PoSh. This workspace is the maintained source of runtime, examples, fixtures, skill and launcher. If absent, use a complete module checkout or the ZIP in that repository's downloads/ directory; do not recreate a second runtime copy in the blog. Confirm the manifest version and available files.
3. QuietCli's actual module implementation, NativeSession.cs, skills/quiet-cli/SKILL.md, Generated-GitOverview.ps1, Generated-NoisyJob.ps1, fixtures and tests. Treat README statements as claims to check against implementation. Record missing PROMPT.md or docs/STACK.md references; never create publication links to missing files.
4. The existing content/blog/rtk-vs-pumps/ series and the current OutputPumps provider documentation when available. Distinguish that system's registry and envelope from QuietCli.
5. Current primary RTK sources: https://github.com/rtk-ai/rtk and its official documentation. Verify claims about handlers, structured analysis, custom filters and recovery. Record URLs, inspection dates and whether a source is a moving branch. Do not treat an old article as proof of current RTK capabilities.
6. Official Git status documentation for porcelain formats, NUL-delimited records, renames and untracked-entry scope.

REQUIRED PAGES
index.md: title, useful-answer introduction, clearly labeled illustrative projection, eight-chapter reading table, runnable entry point, downloadable master prompt and evidence links.
01-from-terminal-output-to-useful-answers.md: the need, local calculations, minimal sufficient answers, common OPumper benefits and different reuse organization.
02-the-agent-writes-the-companion.md: documentation -> contract -> code -> execution -> verification -> reuse; agent versus runtime responsibilities; copyable task instruction.
03-a-result-contract-you-can-trust.md: exact envelope, arbitrary serializable Data, three kinds of completeness, unknown null values, failures, sanitization and budget behavior.
04-a-practical-git-companion.md: supplied overview, branch/detached state, changed versus untracked entries, NUL records and rename handling, normal-mode directory counting, scope and non-atomic observations.
05-streaming-long-running-jobs.md: supplied noisy-job fixture, State/OnRecord/Complete, stdout/stderr, completion evidence, record/capture limits and task-level outcome.
06-compose-tasks-and-reuse-scripts.md: second use of the supplied Git companion, another command and a final projection; preserve inner failure semantics when consuming a companion's JSON.
07-quietcli-opumper-and-rtk-together.md: fair capability comparison, practical choice table, use-case fit, extension costs and lossy chaining risks. Exact calculations should start from documented native formats.
08-costs-limits-and-verification.md: reproducibility, source manifest, report, known limits, initial versus repeated versus maintenance cost, measurement boundaries.

EDITORIAL REQUIREMENTS
Write fluent, concrete English for developers using AI agents. Each chapter must contain 700-1100 words, excluding frontmatter, navigation and fenced code. Develop a practical problem, its mechanism, a useful example and its limits. Avoid padding, repeated introductions, inflated product claims and unsupported superlatives. Distinguish observed outputs, illustrative examples, inferences and unverified claims. The index can be shorter. Add previous/overview/next links. Use a diagram only if it clarifies something prose or a small table cannot; validate it if included.

API AND EXECUTION REQUIREMENTS
Use PowerShell 7.4+ Core only. Preserve the five existing public functions: Invoke-QuietCli, New-QuietResult, Invoke-QuietStep, Invoke-QuietTask, ConvertTo-QuietJson. No API changes are requested.
Use QuietCli's actual SchemaVersion, Summary, Outcome, Data, Execution, Error and Truncation fields. Do not substitute OutputPumps' contract or claim QuietCli has its provider registry.
Data may be an object, array, dictionary, scalar or null. Verify callback cardinality and PowerShell array enumeration against implementation. Unknown is not zero. Outcome success alone does not prove that the domain question is answered.
Use a final budget of 2048 UTF-8 bytes for examples; explain the 4096-byte default. Separate capture/record character limits from serialized byte limits. Inspect and describe the actual behavior when a budget removes Data. Do not claim intelligent field prioritization unless implemented and tested.
Record locally consumed results with Invoke-QuietStep inside Invoke-QuietTask. Emit one final projection and one JSON document. Distinguish interpreter/native success from a parsed inner envelope reporting failed domain execution.
Keep raw stdout, stderr and transcripts local. Do not concatenate executable shell strings or use eval/Invoke-Expression. Preserve authorization and intended command effects; no silent reruns of effectful commands.

EXECUTABLE DELIVERABLES
Maintain runtime, executable examples, verification launcher and skill in QuietCliRoot. Keep the existing runtime API unchanged. Generate downloads/QuietCli.zip and downloads/QuietCli.manifest.json using scripts/New-QuietCliArchive.ps1; include the runtime, actual skill dependencies, examples, fixtures and launcher. Extract the ZIP into a temporary directory, verify its hashes and execute its examples before calling it usable. Do not assume a downloaded SKILL.md installs the runtime. Repair references to absent resources rather than publishing broken links. Preserve source file relationships used by the examples.
Provide a standalone PowerShell launcher accepting QuietCliRoot, Python, optional PythonImage and ReportPath. Use temporary fixtures and safe bounded cleanup. Reuse the supplied Git and noisy-job examples. If host Python is unavailable, allow an explicitly selected existing Podman image with --pull=never, --network=none and only the fixture directory mounted read-only. Label that execution adaptation and never claim the unchanged native Python companion ran in that mode. Add a composition example using the Git overview a second time, inspecting another command locally and returning a domain decision with explicit scope. Verify relative as well as absolute module paths.
Verify document success, malformed JSON, nonzero native exit, timeout, capture overflow, oversized record, final output budget, locally consumed failure, unknown null preservation, clean and modified Git state, untracked-directory entry counting, rename, detached HEAD, reuse/composition and two streaming stages. Report actual observations, versions, pass/fail and limitations. Do not mark unexecuted cases passed. Avoid installing dependencies if working local tools or existing container images suffice; follow applicable permission rules.

RTK COMPARISON BOUNDARIES
Recognize specialized handlers, structured/stateful parsing, filter extensions and documented recovery. Do not reduce RTK to regex filtering. Explain fit, authoring burden and reuse rather than asserting universal superiority. No comparative benchmark campaign is requested. Set RtkExecuted and Benchmark truthfully in the report. Do not assert token, price, latency or memory savings without equivalent executed cases and a stated measurement method. Byte counts are not exact tokenizer counts or total bill savings.

SITE INTEGRATION
Link all module and example code to https://github.com/FrenchExDev/FrenchExDev/blob/develop/PoSh/FrenchExDev/FrenchExDev.QuietCli.PoSh/ and link the downloadable ZIP to https://github.com/FrenchExDev/FrenchExDev/raw/refs/heads/develop/PoSh/FrenchExDev/FrenchExDev.QuietCli.PoSh/downloads/QuietCli.zip. Use tree/develop for directories. Keep reports and the generation prompt on the blog. Do not publish duplicate module/example code or a separate ZIP under the blog. Record that develop is moving and use package hashes to identify the tested contents. Distinguish local preparation from files actually published to GitHub; do not claim remote availability without checking it.
Use lang: en, section: blog, parent: quietcli for chapters, orders 1-8 and category Infrastructure & DevOps. Keep the series independent beside the existing RTK vs Pump-Me series and link them. Update the blog catalogue narrowly. Preserve all pre-existing user changes. Rebuild navigation and rendered pages, inspect the eight-child subtree and served navigation, and verify every published local link, downloadable artifact and code fence. Ensure the master .txt prompt is actually served. Supporting Markdown not in the TOC needs explicit rendering or packaging; never leave a link to an absent HTML file.

ACCEPTANCE AND FINAL CRITICAL REVIEW
Confirm nine pages, chapter word ranges, five-function accuracy, valid runnable instructions, meaningful failure evidence, source hashes and complete local links. Check that no truncated preview is presented as complete, no parser failure is described as an empty success, no unknown count becomes zero and no inner failure disappears in aggregation. Check that source notes distinguish missing original files from working publication links. Compare navigation before/after with only the intended series addition allowed. Identify anything not executed or not verified. Deliver clickable entry points for the series, master prompt and report, plus a concise factual validation summary.