parallax-load-house-view

name

parallax-load-house-view

description

Ingest a CIO house view (PDF / text / URL / wizard) into the Parallax workflow system. Extracts structured tilts and excludes, presents a confirmation gate, then saves the view to ~/.parallax/active-house-view/ where every portfolio skill auto-loads it. Use to set, update, re-pair, extend, or clear the active house view. NOT for portfolio construction (use /parallax-portfolio-builder), not for one-off scenario exploration (just describe inline to the relevant skill).

Load House View

When not to use

• Building a portfolio → use /parallax-portfolio-builder
• One-off scenario / what-if → describe inline to the portfolio skill, don't load as a view
• Single-stock evaluation → use /parallax-should-i-buy

Gotchas

• JIT-load _parallax/house-view/schema.yaml before extraction — it is the single source of truth for the YAML shape
• JIT-load _parallax/house-view/loader.md to see what consumer skills will validate (helps you produce a valid view first time). Note: loader.md §3 (Multiplier mapping) is a normative replay dependency per reasoning chain spec — changes to multiplier values, factor ordering, or composite formula MUST coincide with a skill_version bump and break replay byte-identity for chains pinned to prior versions.
• PDF input — use the Read tool with pages parameter for >10 pages; do NOT defuddle PDFs (we want figure context)
• URL input — use the defuddle skill if Bash is available, else WebFetch
• Confirmation gate is REQUIRED — the uploader must explicitly confirm extracted YAML before save (uploader_confirmed=true). Saving without confirmation breaks downstream loaders.
• Always compute view_hash from the canonical tilts body per schema.yaml §"view_hash computation" — sorted keys, no comments, no empty fields
• Ask uploader_role and basis_statement via AskUserQuestion — these are required-at-institutional fields and need explicit human input
• Auto-applied macro_regime → factor tilts (loader.md §3) MUST be surfaced to the uploader at the gate, not silently applied
• Confirmation gate persists a pre-edit snapshot (Step 3a) when uploader chooses 'Edit specific fields' — writes extractor's pristine draft to .archive/<version>/pre_edit.yaml alongside the superseded view. No-edit confirmations skip this.
• Every extraction attempt (Step 3b) logs an extraction_attempt audit entry to audit.jsonl — whether or not it becomes a save. Capture disposition (confirmed/edited/re_extracted/rejected) + draft_yaml_hash per loader.md §6.2.
• Save (Step 4 step 10) computes a version_diff block vs parent_version_id and stashes it on the save audit entry. Only when this save supersedes a prior version.
• Calibration manifest: Invoke manifest_cache.load_manifest() during Step 4 (Write Phase) to resolve active calibration. Handle DeadStateNoFallback or signature errors by logging a warning and falling back to the bundled-values default.
• Reasoning Chains: Every save MUST invoke chain_emit.emit_chain() (or emit_phase_0_chain()) to produce a compliance artifact at ~/.parallax/reasoning-chains/.
• Compliance Export: Use --export <view_id> to generate a regulator-grade bundle. Validates hash-chain integrity before packaging.
• --why <tilt-path> is on-demand. Reads provenance.yaml first when present; the latest derivation entry for the leaf controls the answer. If type is macro_regime_rule, cite rule_ref + trigger. If type is prose_extraction or no provenance.yaml exists (legacy view), fall back to the prose.md targeted re-read. The saved house view never carries Parallax-derived overlays — augmentation happens just-in-time at consumer-skill use, with provenance recorded on the consuming portfolio/screen artifact, not on the view itself.
• Operator verification: see examples/testing-posture.md

Ingest a CIO house view (PDF / text / URL / wizard) into the Parallax workflow system.

Usage

/parallax-load-house-view <path/to/view.pdf>
/parallax-load-house-view <path/to/view.txt>
/parallax-load-house-view <https://...>
/parallax-load-house-view                          # wizard mode — guided manual entry
/parallax-load-house-view --status                 # show active view summary
/parallax-load-house-view --clear                  # remove active view
/parallax-load-house-view --extend 2026-09-30      # push valid_through forward
/parallax-load-house-view --re-pair                # re-pair after manual prose edit (drift)
/parallax-load-house-view --edit                   # open YAML in editor; re-confirm on save
/parallax-load-house-view --export <view_id>        # export regulator-grade compliance bundle
/parallax-load-house-view --why tilts.factors.momentum             # on-demand: why is this tilt set to what it is?
/parallax-load-house-view --why tilts.sectors.information_technology
/parallax-load-house-view --why factors.momentum                   # bare form — `tilts.` prefix auto-prepended
/parallax-load-house-view --version-history        # show parent chain + per-version diffs from audit.jsonl

Where the view lives

~/.parallax/active-house-view/

• view.yaml — canonical YAML per _parallax/house-view/schema.yaml
• prose.md — verbatim CIO narrative with paired_yaml_hash frontmatter
• provenance.yaml — per-tilt derivation records (prose extraction / macro-regime rule / manual edit)
• audit.jsonl — append-only hash-chained log (consumers append; this skill initializes)
• .archive/<view_id>-<version_id>/ — superseded versions (kept for parent_version_id traceability)

If ~/.parallax/active-house-view/ does not exist, create it on first save. Files are written 0600, the directory is 0700.

Workflow

Call ToolSearch with query "+Parallax" to load the deferred MCP tool schemas before the first mcp__claude_ai_Parallax__* call. JIT-load _parallax/house-view/schema.yaml (canonical structure) and _parallax/house-view/loader.md (consumer expectations) before extraction.

Step 1 — Detect mode and load source

If a path or URL was given: read the source via the appropriate tool. For PDFs:

• ≤10 pages: use Read with pages parameter in one call; proceed to Step 2.
• >10 pages: use streaming extraction — read in 5-page chunks via Read with pages: "N-(N+4)", parse YAML incrementally, merge results. Track extraction_confidence per chunk (if a chunk fails to parse, flag ≤ 0.5 for that chunk and continue). Merged result proceeds to Step 2 with average confidence score across chunks.

For URLs: use defuddle or WebFetch. Skip the wizard and proceed to Step 2.

If no source was given (wizard mode): walk the uploader through the schema interactively in the order below, using one AskUserQuestion invocation per numbered group (not eight separate prompts). Skip any dimension the uploader leaves neutral.

1. Identity: view name, uploader role (CIO / PM / Investment Committee / Strategist / Other), basis statement, effective date, valid_through (or auto_expire_days).
2. Macro regime: growth (slowing / steady / accelerating / null), inflation (disinflation / benign / sticky / accelerating / null), rates (cutting / holding / hiking / null), risk_appetite (risk_on / neutral / risk_off / null).
3. Components: econometrics_phase (macro backdrop), valuation_state (valuation), market_entropy (market state), psychological_wavelength (sentiment) — each on -2 / -1 / 0 / +1 / +2.
4. Factors: value, profitability, momentum, low_volatility, trading_signals — each on -2 / -1 / 0 / +1 / +2.
5. Sectors: present GICS sector keys; uploader picks the ones with a view, then sets each on the same -2 to +2 scale.
6. Regions: present broad keys (developed_markets, emerging_markets, etc.); offer per-country drill-down only if the uploader names specific countries.
7. Styles & themes: offer a free-text follow-up for any thematic conviction.
8. Excludes: free-text list; for each exclude, ask for a one-sentence reason.

Default to multi-select where the schema allows. Capture extraction_confidence as 1.0 for wizard-supplied values (the uploader is the source).

Step 2 — Extract structured tilts

Produce a draft YAML conforming to _parallax/house-view/schema.yaml. For each field, also produce a extraction_confidence score (0.0-1.0) representing your confidence in the extraction.

Component extraction. Before extracting sector/region/factor tilts, read the source for component-level conviction and populate tilts.pillars (field identifier preserved for data-contract stability):

Component	Look for	Map to
econometrics_phase	Macro backdrop framing — "constructive on growth", "recessionary", "stagflation", "soft landing"	+2 very constructive → -2 recessionary/stress
valuation_state	Valuation commentary — "stretched multiples", "cheap vs history", "PE reasonable", "dispersion"	+2 very undervalued → -2 highly overvalued
market_entropy	Technicals/vol/flows — "orderly rotation", "elevated VIX", "breadth deteriorating", "heavy issuance"	+2 low/ordered → -2 high/disordered
psychological_wavelength	Sentiment/RORO — "risk-on backdrop", "frothy retail", "capitulation", "fear index elevated"	+2 very positive → -2 very negative

Components are usually coarse — a prose view rarely articulates sub-factor level. If the source is silent on a component, leave at 0 and flag pillars extraction_confidence ≤ 0.6. Component scores are encoding-only (per loader.md §3): they are stored but do NOT auto-translate into factor multipliers.

Hedged or split-sector language is a known failure mode. When the source uses phrases like:

• "constructive on tech but selective in semis"
• "modestly underweight financials"
• "barbell of growth and value"
• "tactical opportunity"

…do not collapse to a single integer without recording uncertainty. Set the confidence to ≤ 0.7 and note the ambiguity in extraction.extraction_notes.

Factor canonical names. Use profitability (not quality) and low_volatility (not defensive) when extracting fresh. The synonyms remain valid for backward compatibility but new extractions should use the canonical set: value, profitability, momentum, low_volatility, trading_signals.

Region granularity. For prose that names specific countries (Mexico, Brazil, Indonesia, etc.), use the country-level region keys rather than collapsing into broad buckets (em_ex_china, apac_ex_japan). The full country list is in schema.yaml §regions. When the view speaks in broad terms ("EM ex-China overweight"), use the broad key. When specific ("overweight India and Mexico"), use per-country keys.

Macro regime auto-mapping (per loader.md §3): if the source implies a macro regime, populate tilts.macro_regime AND compute the factor-tilt deltas. Show the uploader the raw regime + the resulting factor deltas at the gate so they can override.

Cross-asset views are out of scope. If the source carries views on fixed income, FX, credit, commodities, or alternatives (common in full TAA workbooks), capture them in extraction.extraction_notes as "DROPPED (out of scope):

" so the uploader knows what was lost. Do NOT silently discard.

Required uploader-supplied fields (cannot be extracted from source — ask via AskUserQuestion after extraction):

• metadata.uploader_role (single-select: CIO / PM / Investment Committee / Strategist / Other)
• metadata.basis_statement (free text — what's the basis for this view? IC meeting, strategy memo, regulatory mandate)
• metadata.effective_date (date, default today)
• metadata.valid_through OR metadata.auto_expire_days (date or int; default auto_expire_days = 90)

Step 3 — Confirmation gate (REQUIRED before save)

Architectural note: the saved house view is PURE — it carries only what the source document said + what the uploader confirmed at this gate. Parallax-derived augmentation is deferred to just-in-time lookup at consumer-skill use (e.g., when /parallax-portfolio-builder detects the active view is silent on a dimension it needs for a specific portfolio decision). The augmentation provenance lives on the consuming portfolio/screen artifact, never on the saved house view. The gap_detect and gap_suggest modules in _parallax/house-view/ remain — they get JIT-loaded by consumer skills.

Shared module. The gate display + disposition loop lives in _parallax/house-view/gate_present.py so the in-progress /parallax-make-house-view skill can reuse it. This Step describes how parallax-load-house-view uses the module; the module itself is the source of truth for display rendering and disposition vocabulary. Step 3a (pre-edit snapshot persistence) and Step 3b (extraction_attempt audit logging) remain caller-side responsibilities — the module returns the snapshot in GateResult but never writes audit rows or .archive/<...>/pre_edit.yaml.

JIT-load _parallax/house-view/gate_present.py and construct a GateContext:

• source_label: the filename / URL / "wizard" identifier from Step 1.
• uploader_present=True (ingest framing — "Source:" prefix, extraction verb tense).
• confidence_map: per-category confidence from extraction.extraction_confidence (keys: sectors, regions, factors, macro_regime; the maker path additionally carries pillars, which this skill omits).
• extraction_attempt_action=True (this skill always logs the extraction_attempt row per §3b below).
• disposition_options=["confirm", "edit", "re_extract", "reject"].

Call gate_present.run_gate_loop(draft, context, dispose_fn=..., edit_fn=...). The two callbacks bridge to AskUserQuestion:

• dispose_fn(prompt) -> str — print prompt.display verbatim, then ask prompt.question with prompt.options via AskUserQuestion. Return the chosen disposition keyword.
• edit_fn(current_draft, context) -> (edited_draft, edit_notes | None) — loop on AskUserQuestion per flagged field (the LOW-CONFIDENCE block from the rendered prompt is the suggested order). After all edits land, optionally ask "One line on what you changed and why? (optional)" and pass the response as edit_notes. Return the post-edit draft. The module re-renders the gate and re-invokes dispose_fn until the uploader confirms or branches to a terminal disposition.

The module returns a GateResult with disposition set to one of "confirm", "edited", "re_extracted", or "rejected". Branch as follows:

• "confirm" — proceed to Step 4 with result.final_draft. No pre-edit snapshot to persist. Write the extraction_attempt audit row per §3b with disposition="confirmed" and draft_yaml_hash = sha256(canonical) of result.final_draft.
• "edited" — proceed to Step 3a using result.pre_edit_snapshot (the pristine pre-edit draft, which the module captured automatically on first entry into the edit branch) and optionally result.edit_notes. Then write the extraction_attempt audit row per §3b with disposition="edited" and draft_yaml_hash = sha256(canonical) of the pre-edit snapshot — not the post-edit confirmed draft (that hash goes into view.yaml via Step 4's view_hash). The pair extraction_attempt.draft_yaml_hash + save.view_hash is the audit signature of "what the extractor produced → what the uploader shipped." Proceed to Step 4 with result.final_draft.
• "re_extracted" — discard any holding buffer; do not write pre_edit.yaml. Write the extraction_attempt audit row per §3b with disposition="re_extracted", the rejected draft's hash, and the hint (collected via a follow-up AskUserQuestion). Re-run Step 2 with the hint added to extraction context and return to Step 3.
• "rejected" — discard any holding buffer. Write the extraction_attempt audit row per §3b with disposition="rejected". Abandon; do not write view.yaml.

Step 3a — Pre-edit snapshot (Layer 2)

When the uploader chooses Edit specific fields (not Confirm on the pristine draft):

1. Serialize the current pre-edit draft YAML (the extractor's output, pre-modification) to a holding buffer.
2. After all edits land AND the uploader Confirms the edited version, write the pre-edit snapshot to ~/.parallax/active-house-view/.archive/<new_view_id>-<new_version_id>/pre_edit.yaml. (The directory is the SAME one Step 4 step 9 creates to archive the superseded view — both files share the slot.)
3. Optionally ask the uploader (single question, skippable): "One line on what you changed and why? (optional — press Enter to skip)". If non-empty, save as ~/.parallax/active-house-view/.archive/<new_view_id>-<new_version_id>/edit_notes.md.

If the uploader confirms the pristine draft (no edits), skip Step 3a entirely — there's nothing to snapshot.

Step 3b — Extraction attempt logging (Layer 5, folded into audit.jsonl)

Every extraction attempt — including re-extracts and rejections that never become saves — appends one action: "extraction_attempt" entry to audit.jsonl per loader.md §6.1. Required fields: schema_version, ts, skill, action, applied=false. Conditional: query_summary (source file basename or URL), disposition (one of: confirmed, edited, re_extracted, rejected), draft_yaml_hash (sha256 of the draft the uploader saw; lets us correlate with a later save's view_hash), extraction_duration_ms (optional, wall-clock from extraction start to disposition), hint (when disposition=re_extracted, the hint text truncated to 200 chars).

A successful save after a confirmed draft still emits its own action: "save" entry per Step 4 — the two actions are independent. An extraction_attempt with disposition=confirmed tells you "the uploader confirmed this draft"; the subsequent save tells you "this draft was persisted." Rejected or re-extracted drafts have no matching save.

Step 4 — Compute hashes and write files

On Confirm:

1. Compute view_hash per schema.yaml §"view_hash computation" (pinned algorithm; the reference Python snippet is reproduced in skills/_parallax/house-view/tests/test_view_hash.py). Keep the implementation byte-identical to the reference — any deviation will break hash round-trip. 1a. Load Calibration Manifest (async-ready): Call manifest_cache.load_manifest(fresh_manifest=None) to resolve the active manifest. Capture manifest and status (handle exceptions by falling back to status="PHASE_0_FALLBACK"). If manifest caching supports async lookup, use non-blocking I/O to avoid stalling other Step 4 operations. 1b. Generate Provenance: Create a provenance.yaml artifact capturing the evidence for every non-neutral tilt.
   • Classification (per schema.yaml §"Classification taxonomy"): prose_extraction (LLM-derived from CIO source), macro_regime_rule (auto-mapped per loader.md §3), or manual_edit (uploader edit at confirmation gate). Parallax-derived values are NEVER folded into the saved view — consumer skills carry that provenance per portfolio/screen artifact at JIT use time. (Legacy views may carry an additional parallax_data_fill class from a deprecated ingest-time-augment design; supported for back-compat read but never produced at save time.)
   • Per-class field tables in schema.yaml. Baseline fields shared by all classes: confidence (0.0-1.0), rationale (≤500 chars). Type-specific: source_span (prose_extraction), rule_ref+trigger (macro_regime_rule), prior_value+edit_notes (manual_edit). 1c. Compute Provenance Hash: provenance_hash = sha256(JCS(provenance_data)).
2. Generate metadata.view_id (uuid4) — reuse from existing view if updating same view family; new uuid for new family.
3. Generate metadata.version_id (new uuid4 every save). 3a. Inject Hash: Set metadata.provenance_hash in the draft view.yaml to the value computed in 1c.
4. Set metadata.parent_version_id to the previous version_id if a view existed before this save; null otherwise.
5. Set extraction.uploader_confirmed = true.
6. Set extraction.extracted_at and metadata.upload_timestamp to now (ISO 8601 UTC). 6a. Set metadata.schema_version = 1 (current schema version — see schema.yaml). Every new save writes this; legacy views without it read as v0 at load time. 6b. Set metadata.calibration_status:
   • If status == "ACTIVE" AND manifest.provenance.methodology_section != "GUESS" AND manifest.provenance.backtest_ref is non-null: set to "empirical_phase1".
   • Otherwise: set to "heuristic_phase0".
7. Construct the prose body (the markdown that will live below the frontmatter — verbatim CIO narrative).
8. Compute prose_body_hash = sha256(prose_body_utf8).hexdigest() per schema.yaml §"prose_body_hash computation". The hash is over the bytes that will appear AFTER the closing --- of the frontmatter — not over the whole file. Compute on the finalized body before writing.
9. Write (atomic-safe per-file pattern):
   • Pre-write validation: Before firing any writes, validate that all required fields are set and the directory ~/.parallax/active-house-view/ is writable. If not writable, fail loudly and do not proceed.
   • Stage 1: Compute version-diff BEFORE writes — only when metadata.parent_version_id is non-null (i.e., this save supersedes a prior version in the same view family). Must happen before archiving to avoid async race conditions: 0. Current-view guard. If the current active ~/.parallax/active-house-view/view.yaml does not exist (fresh install), set version_diff_truncated: true with notes: "no_prior_version" on the save audit entry. Do not emit a version_diff field. Continue to save.
     1. Read the current active view.yaml (the prior version being superseded).
     2. Compute a flat diff restricted to the tilts and excludes subtrees (same scope as view_hash) by comparing the prior view.yaml with the new draft. For each dotted path (tilts.sectors.health_care, tilts.factors.momentum, excludes[0], etc.) that differs, record {path: [old_value, new_value]}. Use null for either side when the key is absent on that side. Cap output at 40 entries; if more, truncate and set version_diff_truncated: true.
     3. Stash computed diff for use in Step 11.
   • Stage 1b: Archive (non-blocking, best-effort): After version-diff is computed, archive the current active ~/.parallax/active-house-view/view.yaml and prose.md to ~/.parallax/active-house-view/.archive/<old_view_id>-<old_version_id>/ asynchronously. Archive failures are non-blocking — log a warning but do not abort the save. (The archive is a courtesy; it is not load-bearing for correctness.)
   • Stage 2: Write new files with per-file atomic renames (atomic operation):
     • Write to temporary files in the active directory: For each file to be written, write first to ~/.parallax/active-house-view/<filename>.tmp.<new_version_id>:
       • view.yaml.tmp.<new_version_id>
       • prose.md.tmp.<new_version_id> (with frontmatter four fields in this order: paired_yaml_hash, prose_body_hash, view_id, version_id. Frontmatter is the only part of the file NOT covered by prose_body_hash.)
       • provenance.yaml.tmp.<new_version_id>
       • audit.jsonl.tmp.<new_version_id>
     • Write concurrently: All temporary files write in parallel. If ANY write fails, immediately abort remaining writes and proceed to rollback (Step 9c).
   • Stage 2b: Atomic per-file rename (only if all temporary writes succeeded):
     • For each temporary file, use os.rename(tmp_path, final_path) (POSIX-atomic on same filesystem) to atomically replace the old file with the new one. Use this rename order to preserve atomicity:
       1. view.yaml.tmp.<new_version_id> → view.yaml
       2. prose.md.tmp.<new_version_id> → prose.md
       3. provenance.yaml.tmp.<new_version_id> → provenance.yaml
       4. audit.jsonl.tmp.<new_version_id> → audit.jsonl (rename last)
     • If any rename fails (should be rare): Clean up all *.tmp.<new_version_id> files and fail loudly with "Atomic rename failed on — view not activated. Manual recovery may be needed." The active directory remains in a consistent state (no partial writes, no dangling temp files).
   • Stage 2c: Permission enforcement (post-rename): After all atomic renames succeed, apply permissions concurrently:
     • chmod 0o600 on provenance.yaml (security audit Finding 6 — file carries source-extracted prose snippets; default umask perms would leave it world-readable on shared workstations).
     • chmod 0o600 on audit.jsonl (security audit Finding 5 — closes the window between empty-file creation and the first audit_chain.append_entry). The audit_chain module also re-enforces 0600 on every append as defense in depth.
     • chmod 0o700 the parent dir ~/.parallax/active-house-view/ if it was created in this run.
   • Stage 2c.1: Rollback (only if any write fails during Stage 2): If any file write fails before all temporary files are created, clean up any partial temporary files and report the error: "Save failed: write error. No files written. Safe to retry." Do not proceed to Step 11. The active view remains unchanged.
10. (Moved to Step 9 Stage 1 to avoid async race conditions.)
11. Append Hash-Chained Audit Entry:
    • Prepare entry payload:

      {"schema_version":1,"ts":"...","view_id":"...","version_id":"...","view_hash":"...","skill":"parallax-load-house-view","action":"save","applied":true,"parent_version_id":"...","provenance_hash":"...","version_diff":{...}}
      

    • Invoke audit_chain.append_entry(audit_path, entry_data) to handle prev_entry_hash linking and RFC 8785 canonicalization. 11a. Emit Reasoning Chain (deferred, non-blocking):
    • This step can be deferred to async completion AFTER the save confirmation is returned to the user. It does not block user confirmation in Step 5.
    • Call chain_emit.emit_chain() (or emit_phase_0_chain()) to produce the reasoning chain.
    • Since load-house-view produces a view rather than a portfolio, pass dummy values: base_scores={"response_inline": {}, "response_hash": "0"*64} and final_portfolio={"weights": {}}.
    • Use run_id = "01HZ..." (generate a unique ULID/UUID) and skill_version = "parallax-load-house-view@1.0.0".
    • For emit_chain (ACTIVE status), also pass manifest_dict=manifest, manifest_ref_hash, and signing_payload_hash (from the manifest verification result).
    • Artifact is written to ~/.parallax/reasoning-chains/<YYYY-MM>/<run_id>.yaml.

Step 5 — Confirmation summary

Output to user:

✓ House view saved.
  view_name:    <name>
  view_id:      <uuid>
  version_id:   <uuid>
  effective:    <date> through <date>
  tilts active: <count of non-zero tilt fields>
  excludes:     <count>

Active in: portfolio-builder, rebalance, thematic-screen, morning-brief, client-review, explain-portfolio.
Conflict-flag only in: should-i-buy, deep-dive.

Try it:
  /parallax-portfolio-builder "<your thesis>"     # build a portfolio with this view applied
  /parallax-rebalance [holdings]                  # rebalance against the active view

Audit & inspect:
  /parallax-load-house-view --status              # active view summary
  /parallax-load-house-view --why <tilt-path>     # why is this tilt set to what it is?
  /parallax-load-house-view --version-history     # how did this view evolve?
  /parallax-load-house-view --export <view_id>    # regulator-grade compliance bundle

To clear:  /parallax-load-house-view --clear

Step 6 — Operational modes

Flag	Behavior
--status	Read view.yaml, validate per loader.md §2, then invoke view_status.compute_status() (or shell python -m view_status) to obtain the canonical status. Print the helper's banner field verbatim as the first line, then render the status block defined in §"Status block" below. The banner is the single source of truth for state wording across operator LLMs — do NOT paraphrase. If no view, the helper returns state="none" with the standard "No active house view" banner.
--clear	Archive current view to .archive/, remove view.yaml and prose.md. Append audit entry {"action":"clear"}.
--extend <date>	Update metadata.valid_through only. Bump version_id. Re-pair (recompute view_hash — should be unchanged since tilts/excludes unmodified — and re-write prose.md frontmatter).
--re-pair	Recompute view_hash from current view.yaml and prose_body_hash from current prose.md body. Update prose.md frontmatter paired_yaml_hash AND prose_body_hash to match. Use this after a manual prose edit (body or YAML) when the edit was intentional; the command re-anchors both hashes in one step. Note that re-pair intentionally blesses whatever is currently on disk — run only after you have reviewed the edit.
--edit	Open view.yaml in $EDITOR (default: vi). On save, re-run Steps 3-4 (confirmation gate + write) using the edited content as the draft.
--export <view_id>	Call audit_export.create_bundle() to package view + narrative + provenance + full hash-chained audit trail into a tarball. Fails if audit chain is broken.
--why <tilt-path>	On-demand provenance query. Takes a dotted path (e.g., tilts.factors.momentum, tilts.sectors.information_technology, tilts.macro_regime.growth). JIT-load references/why-provenance.md for path parsing rules, derivation resolution order, and per-source output formats.
--version-history	Read audit.jsonl, filter action="save" entries in the current view family, and render a compact chain: version_id → version_id with the version_diff payload rendered as a short bullet list. If any save has version_diff_truncated: true, note that. Use this to audit how the view evolved.

Status block (output of --status)

The first line is the view_status helper's banner field, surfaced verbatim. The block below follows on the next lines. The helper emits one of seven states (none, malformed, not_yet_effective, expired, critical, warning, active) — see _parallax/house-view/view_status.py and loader.md §2 for the full taxonomy and wording. Do not paraphrase the banner.

<view_status.banner>

Active house view
─────────────────
Name:           <view_name>
Uploader:       <uploaded_by> (<uploader_role>)
Effective:      <effective_date> through <valid_through>   [<days_remaining> days remaining]
Calibration:    <heuristic_phase0 | empirical_phase1>
Schema:         v<schema_version>

Tilts active:   <count of non-zero tilts>
  factors:      <pretty list>
  sectors:      <pretty list>
  regions:      <pretty list>
  themes:       <pretty list>

Excludes:       <count>
  <ticker / sector / theme>  — <reason>
  ...

Audit chain:    <ok | broken (offset N)>
Last consume:   <timestamp> by <skill>
Version chain:  <N versions; latest version_id <truncated>>

The leading <view_status.banner> line covers all non-active states (expired, critical/warning countdowns, not-yet-effective, malformed, none). Do not hand-craft a prefix line — the helper owns the wording, including the days-remaining count and the refresh / --extend / --clear guidance.

Output Format

See Step 5 for the post-save summary. See §"Status block" above for --status. For other operational modes, output the requested success/failure message.

§9.2 exemption: This skill is listed in _NINE_TWO_EXEMPT_SKILLS (_parallax/white-label/tests/test_integration_pattern_referenced.py) and does not render the §9.2 banner itself — it emits a view.yaml configuration artifact, and any LLM-extracted content is gated by Step 3's operator confirmation before it can flow downstream. Each downstream consumer skill renders §9.2 in its own output when it loads the saved view (see parallax-conventions.md §9.2 exemption rationale).

Local-filesystem implementation. A managed, org-keyed version (set_house_view, get_active_house_view, etc., backed by Supabase) is on the roadmap; schema and loader semantics carry forward unchanged.