Update to Clara

{
  "description": "Use when Clara needs budgeting/forecast reports with both variances and Sites delivery, CSV/XLSX/Parquet dataset intake, Sales/Discount/COGS identification, chart capability evidence, dataset profiling, a source-backed dataset semantic layer, mechanical compatibility checks, or reporting contract inspection before chart/report selection.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 274
    }
  ],
  "name": "reporting-engine",
  "skill_md_contents": "---\nname: reporting-engine\ndescription: Use when Clara needs budgeting/forecast reports with both variances and Sites delivery, CSV/XLSX/Parquet dataset intake, Sales/Discount/COGS identification, chart capability evidence, dataset profiling, a source-backed dataset semantic layer, mechanical compatibility checks, or reporting contract inspection before chart/report selection.\n---\n\n<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->\nOnboarding is optional. Continue ordinary professional work immediately,\nincluding direct specialist invocation, without checking or completing a local\nonboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,\nor unavailable voice/window controls, must never block ordinary work. Do not\nautomatically start, resume or repeatedly offer onboarding.\nOnly for a user-requested tutorial or a native teaching handoff, read\n`../clara/references/local-onboarding.md`. A verified paired lesson worker\nexecutes only its bound lesson and token; never bypass tutorial validation.\nTutorial profiles, progress, examples and feedback remain local; never send a\nchange request, stamp a tutorial receipt or call hosted interviews for a tutorial.\nCurrent user requests take precedence over saved preferences.\n<!-- CLARA_OPENAI_ONBOARDING_END -->\n\n## Budget monitoring and forecast reports\n\nFor Actual/Budget monitoring, use `../../modules/reporting-engine/scripts/budget_report.py`\nfrom this skill. This route reuses the management-control calculation core and\nshared IBCS-style reporting table, separately from Business Planning. Run the\nnormal dependency check below (`requirements.txt` includes openpyxl).\n\n1. `python scripts/budget_report.py inspect --input <exports.xlsx> --output-dir <new-inspection-folder>`\n2. Read the bounded inspection and author/review its recipe for the user: source\n   roles, signed amounts, category/account mappings, reporting start/end, closed\n   month cutoff, currency, controls, audience and optional forecast assumptions.\n   Ask only unresolved business decisions; never ask the user to edit JSON.\n3. `python scripts/budget_report.py run --input <exports.xlsx> --recipe <reviewed.json> --output-dir <new-report-folder>`\n4. Read `model_context.json`, not raw populations by default, and prepare\n   commentary from `commentary_template.json`, bound to its metric IDs and pack\n   hash. Treat observations and hypotheses separately; professional review\n   remains explicit. Deliver that explanation with the local report by running\n   `python scripts/budget_report.py run --input <exports.xlsx> --recipe <reviewed.json> --commentary <commentary.json> --output-dir <new-explained-report-folder>`.\n   This replays the original sources, rejects stale commentary and writes the\n   explained dashboard, `management_control_report.md`, the numeric workbook\n   and an execution receipt. Keep the earlier calculation folder intact.\n   Open the native interactive dashboard locally with\n   `python scripts/budget_report_preview.py --report <new-explained-report-folder>/management_control_dashboard.html`\n   and open its returned loopback URL in the Codex browser. This receipt-checked,\n   read-only preview keeps month and cumulative-view controls working; it does\n   not publish or need a Vera client engagement. Keep the server running while\n   reviewing. Use the course document reader for the workbook and Markdown\n   report, not for the interactive HTML; opening HTML as a source file is not\n   a rendered-dashboard check.\n5. If the user requests Sites: `python scripts/budget_report.py site --input <exports.xlsx> --recipe <reviewed.json> --pack <management_control_pack.json> --commentary <commentary.json> --audience <client> --output-dir <new-site-folder>`.\n\nRepeat `--input` for separate exports. The optional `forecast` role uses the same\nreviewed columns as Budget; `forecast_basis` states its source and assumptions.\nActuals through cutoff plus remaining-month estimates form the full-period\nforecast. Do not infer future values or fill missing months with zeros. Complete\nmonthly periods are required; missing months withhold cumulative comparisons.\nBoth amount and percentage deltas remain visible, with unavailable percentages\nfor zero/negative bases. Cost reductions are favorable. Controls only switch\nprecomputed views with common scales; no IBCS certification is claimed.\n\nSet recipe `audience` to internal, client or public_demo; only synthetic examples\nmay use public_demo. Review all content for those readers. This Clara entry point\nuses Clara's selected project/output scope and does not require Vera Studio\nArchive. It does not direct Clara through Vera's client-bound entry points.\n\nThe Sites helper replays sources and the pack, checks audience equality, rejects\nblocked reports and preserves earlier outputs. Publish its exact static `dist`\nthrough Sites using the available hosting capability and existing authorization.\nAll financial views, optional customer/supplier/service labels, commentary and\nlimitations in the HTML reach Sites, including hidden views. Original exports,\nraw populations and full pack JSON are not copied into the public output. No\nautomatic redaction occurs. Verify deployment and visitor access; sending\ninvitations needs authorized recipients. Reuse the Site ID for an explicitly\nrequested, reviewed refresh; there is no automatic recurring update.\n\n## Output Location Rule\n\nNever write run outputs inside this Git workspace, `static/shared`,\n`protected_downloads`, or any GitHub Pages/static-site folder unless the task is\nexplicitly plugin packaging/release. For user-data runs, choose an output\ndirectory outside the repo, preferably a sibling `output/reporting-engine-<run>`\nfolder next to the user-provided input folder.\n\n# Reporting Engine\n\nAfter substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.\n\n## Required handoff for a reviewed report\n\nWhen a reviewed run will leave its execution workspace, include\n`--delivery-dir <new-final-bundle-directory>` in the `run_capability.py`\nexecution command. This exports and verifies the input and render evidence\nalongside the completed run. Without this option, the command reports\n`delivery_required: true`: use the explicit export command below before\ndelivery. Transfer the entire bundle, including hidden files, and verify it\nat its final location. Manual selection or renaming of evidence breaks this\ncontract. Write report links against the final directory layout.\n\nFor any separately authored chart, calculate values and percentages directly\nfrom the full-precision reviewed inputs; round only the displayed labels.\nRetain the generating script and exact inputs. Resolve input paths relative to\nthe delivered script, or accept explicit input/output arguments. Generate from\nthe exported bundle's final paths; do not depend on a temporary working render\ndirectory that will be removed. Test the retained script against the delivered\nlayout before calling it reproducible. After the last visual edit,\ncompute and check the hashes of the final image, script and inputs. An earlier\nimage receipt does not cover an edited image. Invoke\n`advisory-deliverable-validator` on the final report and charts: read its complete\nworkflow and retain `advisory_validation_review.json` and `validation_audit.json`\nfor the exact final report. Reading the skill or verifying render bytes does\nnot complete that review. If a prerequisite is missing, follow the validator's\nmissing-prerequisite path and disclose the unfinished review.\n\nIn the report's reasoning review, separate observed changes from their causes.\nAggregate Sales/Units is average selling price: its change can reflect product\nmix as well as within-product price changes. Do not attribute sales growth to\nprice alone without the corresponding decomposition, or to margin merely\nbecause the margin rate increased. State descriptive movements and unresolved\ndrivers when the evidence does not establish causation.\n\nThe monthly period-comparison renderer includes a period-to-date monthly\naverage column: a label such as `_FebÆ` is its intentional IBCS notation,\nnot an extra month or corrupted source category. Inspect its recipe and values\nbefore judging the column. Explain it in the report when retaining it; a\nseparate chart omitting it needs its own calculation and artifact evidence.\n\n## Short descriptive summaries\n\nFor a short request limited to descriptive statistics over readable local data,\nsuch as counts, median, range or missing values, inspect the source, units and\nmissing-value treatment and calculate with already available local tools. The\nPython standard library is sufficient for a simple CSV summary. Return the\nrequested summary with its source and interpretation limits; do not initialize\na semantic project, run dependency setup or create a reporting run merely to\nanswer that request. This is a descriptive summary, not a reviewed Reporting\nEngine execution or a calculation receipt for downstream professional handoff.\n\nUse the full intake and reviewed execution below for chart selection, governed\nreports, reusable dataset semantics or case contributions. A short summary must\nnot be used to manufacture those acceptance receipts or bypass their checks.\n\nIf the user forbids Internet access, do not run dependency checkers or launchers\nthat may install packages. Use an already prepared runtime for a full workflow;\nif none is available, explain the limitation and complete only the supported\nlocal work. Do not attempt an unmanaged import as a workaround.\n\n## Reporting contracts and execution\n\nReporting Engine is Clara's reporting contract component. It packages the\nreviewed chart-selection manifest, gallery artifact metadata, role registry,\nfamily selector playbooks, Clara adapter registry, stable dataset semantic\ncontract, and a unified rendering entrypoint. Reviewed semantic layers for user\ndata are persistent project objects outside the repository. Dataset profiles,\nsnapshot attachments, compatibility audits, and render proofs are per-run\nartifacts outside the repository.\n\nThe canonical component root is `../../modules/reporting-engine` relative to\nthis skill directory in both the editable Clara source and installed Clara\npackage. Run component helpers with that directory as the working directory.\nThere is no standalone Reporting Engine plugin or fallback source tree.\n\nUse this component to answer mechanical questions:\n\n- what chart capabilities exist;\n- what roles a chart needs;\n- which `reporting-engine.*` adapter owns the chart contract;\n- which legacy plugin source is only provenance for that adapter;\n- how to render a chosen capability through the adapter boundary;\n- how to prove the exact input, effective request/recipe, and output bytes for\n  that render;\n- what dataset columns are candidate periods, metrics, dimensions, or\n  identifiers;\n- which reviewed metric, if any, represents Sales, Discount, or COGS, and\n  whether any role is absent or ambiguous;\n- whether a dataset is mechanically compatible with a chart;\n- how to create, review, and validate a dataset-specific semantic layer that\n  defines metric meaning, aggregation, dimensions, periods, and valid analyses.\n\nMaterial choices for this component are limited to the dataset path, output\nfolder, chart family or capability filter, and whether optional render-library\nrequirements should be checked. They are not choices to propose as a substitute\nfor evidence. Inspect the actual inputs first; ask only those unresolved choices in chat. Do not introduce chart, metric, or dimension choices unless the facts cue them.\n\nDo not treat the generated scaffold or deterministic validator as semantic\njudgment. The scaffold marks every concept `unknown`. Codex or a human must\ninspect source evidence and author or review business meaning and analysis\nvalidity, including whether Sales, Discount, and COGS are mapped, absent,\nambiguous, or still unknown. A matching header is not enough to promote a\ncandidate automatically. Create semantics once for a stable caller-,\nconnector-, or project-assigned dataset contract id. On later uploads, reuse\nthat semantic version through snapshot compatibility; never regenerate\nsemantics merely because values, rows, members, or date bounds changed. A\n`contract_valid` result proves coherent wiring only; it does not prove the\nsemantic claims are true or choose the final chart.\n\nLocal data and deterministic-script ownership are part of this workflow.\nDeterministic scripts own manifest loading, dataset profiling, role-candidate\nextraction, semantic document scaffolding, reference and role-binding checks,\npackage contract inspection, and mechanical compatibility evidence. Codex owns\nsource-backed semantic authoring and interpretation and must keep those\njudgments separate from deterministic validation.\n\nExplicit approval is reserved for external, destructive, approval-sensitive, or\nmaterial steps such as network access, deployment, package release, deleting\nfiles, overwriting user data, or changing the canonical manifest. Local\nread-only inspection, profiling into a user-chosen output folder, and contract\nsummaries can proceed without an approval checkpoint.\n\nBefore running component helper scripts, run this from the Clara plugin root:\n\n```bash\npython scripts/check_dependencies.py --module reporting-engine\n```\n\nThis prepares and checks the component's declared managed runtime. For chart\nrendering, add `--include-optional` so setup includes `requirements-render.txt`\nand selects the same runtime as the render command. Host Python imports do not\ndescribe what is installed in that managed runtime. Run the remaining commands\nbelow from `modules/reporting-engine`.\n\nIf setup fails, retain the exact command, exit status and complete error output\nin the run's diagnostic evidence before attempting anything else. Report the\nfailure if the declared setup cannot complete. Do not install directly into a\ngeneration, call private runtime helpers, or write readiness receipts or active\npointers yourself. Those actions bypass the setup evidence and cannot establish\na successful Reporting Engine execution. `bootstrap_python_dependencies.py` is\nthe core SessionStart hook, not a replacement for module-specific setup.\n\nFor semantic-layer creation or review, read\n`../../modules/reporting-engine/references/semantic_layer.md` relative to this\nskill directory before authoring the dataset-specific JSON. The reference is\ninside the component, not this wrapper skill's directory.\n\nWhenever the user supplies a CSV, XLSX, or Parquet dataset, run\n`scripts/dataset_intake.py` before chart compatibility or selection. On a first\nupload, inspect the generated authoring context, the actual data, and available\nsource evidence; then author the semantic layer for the user. Explicitly review\nSales, Discount, and COGS. Map a role only to a source-backed reviewed metric;\nrecord `absent` only when the evidence establishes no separate measure; record\n`ambiguous` when plausible candidates remain unresolved; otherwise keep\n`unknown`. Never ask the user to edit JSON. Ask one focused business question\nonly after the available files and sources cannot resolve a material ambiguity.\nSave the reviewed layer as persistent project data outside the repository.\n\nOn later uploads, pass the same stable contract id and persistent reviewed layer\nback to `dataset_intake.py`. Reuse an accepted mapping; do not infer identity\nfrom a similar schema, overwrite the persistent layer, or silently create a new\ncontract after rejection. This workflow is local to Clara/Codex and does not\ndepend on a FastAPI upload route.\n\nUseful commands:\n\n```bash\npython scripts/reporting_contract.py\npython scripts/reporting_adapters.py\npython scripts/reporting_adapters.py --capability period_comparison.trend --plan\npython scripts/reporting_contract.py --capability period_comparison.trend\npython scripts/dataset_intake.py <dataset.csv> --dataset-contract-id <stable-id> --output-dir <run>\npython scripts/dataset_intake.py <new-snapshot.parquet> --dataset-contract-id <stable-id> --semantic-layer <project-data>/semantic_layer.json --output-dir <run>\npython scripts/profile_dataset.py <dataset.csv> --output <run>/dataset_profile.json\npython scripts/semantic_layer.py init --profile <run>/dataset_profile.json --output <run>/semantic_layer.json\npython scripts/semantic_layer.py context --profile <run>/dataset_profile.json --layer <run>/semantic_layer.json --output <run>/semantic_authoring_context.json\npython scripts/semantic_layer.py validate --profile <run>/dataset_profile.json --layer <run>/semantic_layer.json --output <run>/semantic_validation.json\npython scripts/semantic_layer.py attach --profile <run>/new_snapshot_profile.json --layer <run>/semantic_layer.json --output <run>/snapshot_attachment.json\npython scripts/check_compatibility.py <run>/dataset_profile.json --output <run>/compatibility.json\npython scripts/render_capability.py period_comparison.trend <dataset.csv> --output-dir <run>/render --role-bindings-json '{\"period_axis\":\"Date\",\"comparison_metric\":\"Sales\"}' --options-json '{\"current_period_label\":\"<current-period>\",\"previous_period_label\":\"<baseline-period>\"}' --artifact-mode data_only\npython scripts/mechanical_acceptance.py --suite --output-dir <empty-run-dir> --execute --artifact-mode data_and_render\n```\n\nCurrent boundary:\n\n- the manifest and gallery artifact metadata are packaged as product contract\n  evidence;\n- every manifest capability resolves to a Clara-owned reporting-engine adapter;\n- `scripts/render_capability.py` is the low-level diagnostic render entrypoint for a chosen\n  capability;\n- each `render_manifest.json` uses schema `0.2` and records SHA-256 plus byte\n  counts for the input and every current-run output, a canonical request\n  digest, effective-recipe evidence, and an output-set digest; every invocation\n  renders inside a fresh isolated directory so a pre-existing artifact never\n  counts as current-run by mere presence;\n- old chart-family plugin names are provenance, not the caller-facing boundary;\n- the chart-family components are embedded in Clara and called through the\n  unified render entrypoint;\n- the profiler creates runtime dataset-side role candidates;\n- `scripts/dataset_intake.py` is the first local entrypoint for CSV, XLSX, and\n  Parquet files; it writes the profile, draft/context or compatibility\n  attachment, and an intake receipt without making hidden semantic decisions;\n- `catalog/semantic_layer.schema.json` defines a persisted stable dataset\n  semantic contract with explicit identity and semantic version;\n- `scripts/semantic_layer.py` creates an unreviewed scaffold, packages all 48\n  manifest analysis types for model-led review, validates evidence and\n  canonical-role bindings, attaches mechanically compatible snapshots, and\n  resolves reusable period rules into snapshot-specific bounds;\n- equal schemas never establish logical dataset identity; the caller, source\n  connector, or project configuration must supply the stable contract id;\n- changed values, rows, members, and date bounds do not invalidate semantics;\n  missing or role-incompatible bound fields disable affected analyses;\n- reviewed analysis policies use manifest task and selection-emphasis ids as\n  join keys but do not contain or choose a final chart id;\n- `contract_valid` and `semantic_readiness` are separate: a mechanically valid\n  draft remains `draft_unreviewed`;\n- canonical Sales, Discount, and COGS mappings remain `unknown` until\n  source-backed model or human review records them as mapped, absent, or\n  ambiguous;\n- unlisted manifest analysis emphases remain `unknown`; a reviewed semantic\n  layer is ready only within its declared scope and does not need one policy per\n  chart;\n- compatibility evidence distinguishes required roles from optional roles,\n  reports candidate and ambiguous columns for both, and only rejects missing\n  required roles;\n- period-filter charts require a bounded scope or an explicit all-data request,\n  while period-axis charts may intentionally use the available range;\n- comparison charts require distinct current and baseline periods;\n- the root-cause exploded bridge binds a generated alternative driver sequence\n  and then one or more one-based drilldown rows; neither choice is hidden in the\n  renderer;\n- the packaged mechanical acceptance suite currently executes and render-proves\n  all 48 capabilities against synthetic fixtures;\n- the packaged semantic fixture proves nine valid analysis policies bind\n  complete manifest role sets and one unsupported statement analysis remains\n  explicitly invalid;\n- Clara may use the evidence to narrow chart choices;\n- automatic chart selection and full report orchestration are intentionally not\n  implemented here.\n\nWhen a rendered data artifact feeds an HTML deck, seal that CSV or JSON into\nthe HTML Deck `clara.evidence_bundle.v1` contract and bind the prepared series\nor cell. Never copy values from the render manifest into prose or a plot spec.\nThe current renderer still accepts one input file (except the attribute-package\nboundary). Multi-source analytical work must first use reviewed semantic and\nrelationship decisions to materialize deterministic evidence tables; the\nrenderer must not infer cross-source joins.\n\nWhen a Reporting Engine result introduces or updates a claim in a Clara case,\nrecord the model-authored claim and calculation meaning through the shared\nhandoff helper:\n\n```bash\npython scripts/record_reporting_contribution.py \\\n  --case-dir <case-dir> \\\n  --render-manifest <run>/render_manifest.json \\\n  --contribution <model-authored-reporting-contribution.json> \\\n  --verification-artifact <run>/semantic_validation.json \\\n  --verification-artifact <run>/compatibility.json\n```\n\nThe contribution JSON supplies the semantic observation, scope, limitations,\nmethod, full claim record, and optional judgement projection. The helper does\nnot infer them. It verifies the authoritative Reporting Engine 0.2 result,\ninput, recipe, current-run outputs, output-set digest, and added verification\nfiles, then creates the `calculation_run` receipt and commits the receipt,\nclaim, and judgement projection atomically. The claim must reference that\nreceipt in both `evidence_links` and `calculation_evidence_id` and names any\nupstream claim dependencies. This cross-workflow receipt lets the advisory\nvalidator find and selectively rerun the exact calculation; it does not replace\nReporting Engine's semantic review, compatibility checks, calculation logic,\nor render proof.\n\n### Execute from reviewed semantics\n\nAfter semantic acceptance, prefer `scripts/run_capability.py` for a supported\nreviewed analysis. It derives role columns, currency and period scope from the\naccepted policy instead of taking fresh caller overrides:\n\n```bash\npython scripts/run_capability.py <dataset> --layer <semantic_layer.json> --profile <dataset_profile.json> --acceptance <acceptance.json> --source <reviewed-source-notes> --analysis-id <reviewed-policy-id> --capability-id <selected-capability> --output-dir <run>/render\npython scripts/run_capability.py --verify-output <run>/render\n```\n\nRepeat `--source` for every source bound in acceptance. Verify again before\nregistering an analysis contribution and bind `reviewed_execution.json` as an\nexact-basis evidence artifact together with the selected output. A changed\nsource, semantic layer, profile or rendered artifact invalidates that handoff.\nThe receipt proves execution against declared reviewed inputs, not the truth\nof a business conclusion or professional approval of the deliverable.\n\nThe current compiler rejects unmaterialized derived metrics, grouped weighted\naggregations, compound bindings and unsupported period-window adapters. Keep\nthose requirements visible and use the owning preparation workflow; never\nchange a metric's aggregation rule or use a diagnostic run to bypass the gap.\n`render_capability.py` remains available for mechanical diagnostics. Its output\nalone is not proof of execution under reviewed semantics.\n\n### Keep intake parser settings through rendering\n\nFor Excel or a non-default CSV dialect, carry the selected table settings from\n`dataset_profile.json` into `render_capability.py --parser-settings-json`.\nFor example, use `'{\"sheet_name\":\"Reviewed\"}'` for that exact Excel sheet or\n`'{\"csv_options\":{\"separator\":\";\",\"decimal_comma\":true}}'` for a reviewed\nregional CSV. The renderer parses once, supplies a normalized UTF-8 CSV to the\ncomponent, and records the parser settings and normalized-byte hash. Temporary\nnormalized input is removed after the run; the source stays unchanged.\nDo not change settings to obtain a passing chart. Return to intake if the\nselected sheet, parsing contract, or source bytes differ from the reviewed input.\nThese checks establish parsing identity, not semantic approval of the analysis.\n\n\n## Codex-Native Run UX\n\nFor full reporting execution, inspect the manifest contract, run dataset intake when a tabular file is\nprovided, create or load the dataset semantic layer, review Sales/Discount/COGS,\nvalidate its evidence and role bindings, and compare required chart roles with\nrole candidates. Report the result concisely; a checklist or intake table is\noptional, while the semantic and mechanical checks remain required. For a short\ndescriptive summary, follow the bounded path above instead.\n\nDefault output policy: write user artifacts outside this repository. Catalog\nchanges, generated ZIPs, and package checks are allowed inside the repo only\nwhen the task is explicitly plugin packaging or release.\n\nWhen a table helps explain compatibility, show facts and evidence: chart\ncapability, required roles, matched dataset columns, missing\nroles, ambiguous roles, invocation contract status, and render-proof status.\n\nUse an execution checkpoint before claiming a chart family is ready: the\nmanifest must load, the dataset profile must exist when relevant, the semantic\nlayer must be reviewed for any semantic claim, mechanical compatibility must be\nshown, and any missing role must be visible. If a run creates persistent\nartifacts, include a `codex_run_review.md` file that links the manifest, dataset\nprofile, semantic layer, semantic validation, compatibility table, and any final\nJSON outputs.\n\nBefore delivery, reconcile each diagnostic with its own scope. Unresolved\nbindings in an analysis policy and missing roles in a dataset compatibility\ncheck are different populations. Do not merge their counts or describe\navailable columns as absent. Explain the\nsource-backed reason an analysis is unsupported; mechanical compatibility alone\ndoes not establish professional feasibility or the truth of that judgment.\n\nResolve every review-index and report link from the file that contains it,\nafter copying the final bundle to its delivery location. Retain the referenced\nevidence there. A separately authored chart is a new artifact: identify it as\nsuch, retain its generation source and input identity, and check its displayed\nvalues. Do not attribute the packaged renderer's byte proof to that replacement.\n\nReporting publication uses `current_reporting.json` as the current-generation\npointer. Completed generations live under `.reporting-generations/` and contain\nthe exact render manifest, outputs and generated recipe. Working copies in the\noutput directory may be replaced during another attempt. Before handoff, use\n`run_capability.py --verify-output <output-dir>`; its `publication` result gives\nthe verified generation directory and checks that its manifest is exactly the\nreviewed one. Deliver artifacts from that generation. A running or failed\npointer is not a successful current render, even if older files still exist.\nThese byte checks do not validate chart interpretation or business conclusions.\n\nFor delivery outside the execution workspace, export the complete verified run:\n\n```bash\npython scripts/run_capability.py --export-output <output-dir> --delivery-dir <new-delivery-dir>\npython scripts/run_capability.py --verify-output <new-delivery-dir>\n```\n\nThe export copies the reviewed source inputs, preserves original receipt and\nartifact names, and includes the current hidden generation directory. Keep the\nentire exported directory together when transferring it, including hidden\nmembers and `reporting_delivery.json`. Do not manually select or rename its\nevidence files. Use the exported descriptor's actual relative input paths when\nreferencing the semantic layer or source notes. Verify the transferred bundle\nagain at its final location. A successful verification prints `status: verified`;\nit proves byte identity and reviewed input wiring, not the report's conclusions.\nAuthor the management report and its links against this final file layout.\n\nBefore delivering, review the actual report and charts with\n`advisory-deliverable-validator`. Check the report's unsupported-analysis\nexplanation against the sources; a missing mechanical role is evidence about\nan adapter contract, not proof that a professional conclusion is \"not a\njudgment call\". Inspect each chart at its delivery size for clipped titles,\nlegends and source notes. For a separately authored chart, keep its generating\nscript and exact input references alongside it. If the user requests an\nindependent run excluding earlier outputs, do not read them for formatting or\nother context either.\n"
}