Overview
${escapeHtml("Panel Manifest defines the machine-readable entry manifest for the Devon panel and documentation surface. It exists to provide a deterministic panel bootstrap surface, bind the entry layer to canonical ownership without redefining it, and keep panel initialization aligned with the sovereign architecture. It fits in Phase 01 under Overview & Scope as the entry manifest and machine-readable panel entry point. Downstream, it matters because it reduces bootstrap ambiguity, supports predictable panel boot order, and helps keep Documentation Hub, Panel, and canon aligned from the entry layer onward. It is support-level machine-readable authority for panel entry, depends on master_architecture_index, and must not override the master’s sovereignty.")}
`;
const prerequisitesBuckets = [
{
title: "Definition and canonical role",
items: [
"Panel Manifest prerequisites define the minimum mandatory structural, operational, documentary and validation conditions that must exist before the Panel can initialize, read, organize and render system state from real evidence.",
"The Panel does not interpret architecture, does not create local truth, does not calculate sovereign meaning and does not infer missing context.",
"Its role is limited to consuming valid contracts, reading observable artifacts and projecting visually what the Devon environment has already produced, registered and synchronized.",
"Because of that, any missing, inconsistent or invalid prerequisite compromises interface trust directly and invalidates Panel reliability by definition.",
"The existence of prerequisites is not conceptual. Every prerequisite must be materially observable, structurally bounded and subordinate to canonical authority."
]
},
{
title: "Fundamental principle",
items: [
"The Panel operates exclusively from observable evidence, valid contracts and correct structural linkage to the sovereign architecture.",
"The operating rule is binary: if it exists, is integral and is functional, it is valid.",
"If it does not exist, it is nonexistent.",
"If it exists but does not function, it is invalid.",
"There are no intermediate states, approximations or assumptions in Panel bootstrap legitimacy."
]
},
{
title: "Architectural role of prerequisites",
items: [
"Panel Manifest prerequisites are not optional dependencies. They are the structural base that makes the Panel legitimate as a canonical reading surface.",
"They sustain the integrity of the Documentation Hub as projected documentary plane.",
"They sustain the coherence between Master Architecture Index and panel-readable contracts.",
"They sustain the truthfulness of the data shown in the UI.",
"They sustain synchronization between Devon and Waresite.",
"They sustain system auditability and deterministic interface bootstrap.",
"Without valid prerequisites, the Panel may still exist visually, but it cannot be treated as a trustworthy surface."
]
},
{
title: "Layered prerequisite structure",
items: [
"Architecture layer: master registration, scope framing, deployment order and structural contracts must already exist so Panel Manifest has origin, fit and bounded role.",
"Delivery layer: collection and publication mechanisms must already exist so the Panel receives current structured data instead of stale assumptions.",
"Runtime layer: real host, container, status, progress and snapshot artifacts must already exist because the Panel has no truth of its own.",
"Integration layer: export, synchronization and transfer from Devon to Waresite must already work so the Panel reflects real operational state.",
"Interface layer: the Panel itself must remain limited to reading, interpreting contracts and rendering, never compensating for missing data with local logic.",
"Trust layer: validation and integrity controls must already exist so the Panel only consumes data that is structurally compliant and operationally trustworthy."
]
},
{
title: "Canonical operating rules",
items: [
"The architecture base must exist and remain integral.",
"Panel Manifest must be registered and correctly positioned inside Phase 01 overview_scope.",
"Runtime must be collected and published continuously.",
"Data must be valid and structurally well-formed.",
"Integration between Devon and Waresite must remain active.",
"The interface must consume only real data.",
"Validation must confirm integrity and conformity.",
"The Panel must remain subordinate to canonical authority and must never redefine architectural meaning locally."
]
},
{
title: "Failure conditions",
items: [
"Absence of the sovereign architectural registration source invalidates Panel bootstrap legitimacy.",
"Loss of the entry manifest or loss of its structural identity invalidates deterministic interface startup.",
"Missing runtime data invalidates any visual projection.",
"Present but structurally invalid data invalidates the interface just as much as absent data.",
"Synchronization failure between Devon and Waresite breaks reality reflection.",
"Interface output without proven source origin is invalid.",
"Divergence between contract and execution is invalid.",
"Any local Panel-side interpretation of meaning that should come from published artifacts violates the system law."
]
},
{
title: "Nature of prerequisites",
items: [
"Panel Manifest prerequisites are not an implementation checklist. They are an existence contract.",
"Each item is a condition that must be provable continuously for the interface to remain legitimate as a reading surface.",
"The system does not ask whether something should exist.",
"It verifies whether it exists now, is integral now and remains bound to the correct authority now."
]
},
{
title: "Expected result and exit rule",
items: [
"When all prerequisites are valid, the Panel has a clear structural entry point and deterministic bootstrap behavior.",
"There is no gap between what the interface shows and what Devon has actually published.",
"System reading begins from a stable and legible manifest rather than scattered assumptions.",
"Audit of bootstrap and UI projection becomes trivial because the entry layer is bounded and observable.",
"Panel Manifest prerequisites are complete only when entry identity, architectural linkage, evidence dependency and trust boundaries are materially valid.",
"If the manifest entry layer remains ambiguous, no downstream Panel artifact may be treated as ready.",
"Prerequisite completion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const configurationBuckets = [
{
title: "Definition and configuration role",
items: [
"Panel Manifest configuration defines how the panel entry manifest must be structurally arranged so the interface can bootstrap from a deterministic and machine-readable entry surface.",
"Configuration here means canonical arrangement, binding and operational shape, not cosmetic UI preference.",
"Its role is to ensure that the Panel Manifest remains stable as entry support for panel-side reading, tree resolution, content projection and contract alignment.",
"A configured Panel Manifest must remain structurally predictable across architecture, contract and source views."
]
},
{
title: "Document identity configuration",
items: [
"Panel Manifest must keep a fixed document id, label, path, phase and layer identity.",
"Its registration under overview_scope must remain stable in hub_index.json.",
"Its type must remain machine-readable and coherent with its role as panel entry support artifact.",
"Configuration is invalid if the same document resolves under conflicting identities across the UI."
]
},
{
title: "Canonical binding configuration",
items: [
"The manifest must remain subordinate to master_architecture_index sovereignty.",
"Its configuration must preserve explicit linkage to project scope and deployment order.",
"Sovereign/support separation must remain visible in how the manifest is described and consumed.",
"The manifest may configure panel entry behavior, but it may not redefine architectural authority."
]
},
{
title: "Tree and selection configuration",
items: [
"Panel Manifest must be configured to appear in the correct category and order inside the architecture tree.",
"Its selection path must resolve deterministically when clicked from the left navigation.",
"Its architecture route, contract route and source route must all point to the same underlying document identity.",
"Configuration is incomplete if UI selection can drift into another document payload."
]
},
{
title: "Bootstrap configuration",
items: [
"The manifest must be configured as the panel entry surface for downstream panel-side reading.",
"Its structure must be stable enough to seed tree logic, navigation logic and content mapping without ambiguity.",
"Downstream panel contracts must be able to inherit entry context from the manifest.",
"The bootstrap configuration must eliminate dependence on scattered assumptions or implicit ordering."
]
},
{
title: "Rendering configuration",
items: [
"Panel Manifest must be configured to render through the structured category scaffold in architecture mode.",
"Its card layout must remain compatible with the same category model used across the documentation plane.",
"Its architecture rendering must not collapse into fallback summary unless source loading genuinely fails.",
"Its configuration is invalid if the selected manifest renders another document payload."
]
},
{
title: "Source and contract configuration",
items: [
"Source view must expose the real underlying document for Panel Manifest.",
"Contract view must describe the same registered artifact seen in architecture mode.",
"Architecture, contract and source views must stay configuration-consistent.",
"Any route divergence between those three views invalidates configuration integrity."
]
},
{
title: "Dependency and sync configuration",
items: [
"The manifest must remain configured in a way that downstream panel tree, navigation spec, content index and blueprint can consume consistently.",
"Its configuration must align with the Devon-to-Waresite projection model.",
"It must not depend on hidden local UI state to remain readable.",
"Configuration must remain stable across reload, re-selection and mode switching."
]
},
{
title: "Misconfiguration conditions",
items: [
"If the manifest appears in the tree but resolves to the wrong architecture payload, configuration is invalid.",
"If the manifest has a valid source but inconsistent contract projection, configuration is invalid.",
"If the manifest depends on fallback behavior to render architecture, configuration is incomplete.",
"If the manifest loses canonical linkage while remaining selectable in the UI, configuration is invalid."
]
},
{
title: "Configuration exit rule",
items: [
"Panel Manifest configuration is complete only when document identity, canonical binding, tree placement, selection routing, rendering behavior and cross-view consistency are materially stable.",
"No downstream panel artifact may be treated as configuration-ready if the Panel Manifest entry layer still depends on ambiguous routing or unstable identity.",
"Configuration completion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const observableEvidenceBuckets = [
{
title: "Definition and evidence role",
items: [
"Panel Manifest observable evidence defines the set of materially inspectable signals that prove the manifest exists, is correctly registered, is routed to the correct payload and is being rendered from the correct document identity.",
"Observable evidence here is not conceptual confidence. It is concrete evidence that can be inspected in file registration, UI selection behavior, mode switching and rendered output.",
"Its role is to prove that the Panel Manifest is not only declared in architecture, but materially reachable and operationally projected in the Documentation Hub.",
"If a condition cannot be observed, it cannot be claimed as valid evidence for Panel Manifest."
]
},
{
title: "Document existence evidence",
items: [
"Panel Manifest must exist as a real registered document in the documentation system.",
"Its document id must be observable as panel_manifest.",
"Its label, path, phase and layer identity must be materially present in the registered document set.",
"Evidence fails if the manifest is referenced in logic but not materially registered as a document."
]
},
{
title: "Hub registration evidence",
items: [
"Panel Manifest must be observable inside hub_index.json under overview_scope.",
"Its placement in the category docs list must be materially visible.",
"Its registration must be stable enough to survive reload and re-render.",
"Evidence fails if the manifest is only implied by code and not present in hub registration."
]
},
{
title: "Tree visibility evidence",
items: [
"Panel Manifest must appear in the left architecture tree under Overview & Scope.",
"Its label must be visibly selectable from the UI.",
"A user click on Panel Manifest must be observable as a stable document selection event.",
"Evidence fails if the tree shows the label but selection resolves to another artifact."
]
},
{
title: "Render-path evidence",
items: [
"Architecture mode must visibly render Panel Manifest-specific cards and text rather than inherited content from Master Architecture Index.",
"Contract mode must visibly describe the same Panel Manifest artifact.",
"Source mode must visibly expose the real underlying source for Panel Manifest.",
"Evidence fails if any mode shows fallback content, wrong payload or cross-document contamination."
]
},
{
title: "Identity consistency evidence",
items: [
"The same Panel Manifest identity must be observable across architecture, contract and source views.",
"The selected document must not silently switch to Master Architecture Index or another sibling artifact.",
"Route stability must remain observable during mode changes and reselection.",
"Evidence fails if the UI presents one label while the payload belongs to another document."
]
},
{
title: "Content integrity evidence",
items: [
"The visible text under Panel Manifest must correspond to Panel Manifest context and not to another category or document.",
"Overview, Prerequisites, Installation, Configuration and downstream cards must remain context-consistent with panel entry manifest behavior.",
"Observable evidence must show that rendered text changes when Panel Manifest-specific content is updated in code.",
"Evidence fails if the UI continues to show stale or inherited content after document-specific updates."
]
},
{
title: "Operational evidence of deterministic bootstrap",
items: [
"Panel Manifest must be observably usable as an entry support artifact for panel-side reading.",
"Its presence must support deterministic tree resolution, content projection and contract alignment.",
"The manifest must remain observably stable as a panel entry surface under reload and reselection.",
"Evidence fails if bootstrap stability depends on hidden cache, ambiguous routing or lucky UI state."
]
},
{
title: "Failure evidence",
items: [
"A wrong payload rendered under Panel Manifest is observable failure.",
"Fallback summary rendered instead of the custom architecture payload is observable failure.",
"Missing source while architecture or contract still appears valid is observable failure.",
"Mismatch between tree label and rendered content is observable failure."
]
},
{
title: "Observable evidence exit rule",
items: [
"Observable evidence for Panel Manifest is complete only when document existence, hub registration, tree visibility, payload identity, render-path integrity and cross-view consistency are all materially inspectable.",
"No downstream panel artifact may be treated as trustworthy if Panel Manifest evidence is still indirect, inferred or fallback-driven.",
"Observable evidence completion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const completionPromotionBuckets = [
{
title: "Definition and promotion role",
items: [
"Panel Manifest completion and promotion define when the manifest entry layer can be treated as structurally complete and eligible to unlock downstream panel-facing artifacts.",
"Completion here does not mean the document merely exists. It means the manifest is materially present, correctly routed, canonically bound, render-stable and cross-view consistent.",
"Promotion here means the entry layer is trusted enough to support downstream panel tree, navigation, content projection and contract consumption without ambiguity.",
"A promoted Panel Manifest must already operate as a deterministic panel entry surface."
]
},
{
title: "Completion criteria",
items: [
"Panel Manifest must be registered as a real document under overview_scope.",
"Its tree placement, selection behavior and render path must be materially stable.",
"Its architecture, contract and source modes must remain aligned to the same document identity.",
"Its content must be context-correct and free from inherited payload contamination.",
"Its support-level role must remain subordinate to master_architecture_index sovereignty."
]
},
{
title: "Promotion gates",
items: [
"No promotion is valid if Panel Manifest still depends on fallback-driven architecture rendering.",
"No promotion is valid if UI selection can still resolve to the wrong payload.",
"No promotion is valid if cross-view identity remains unverified.",
"No promotion is valid if canonical linkage to overview roots is still ambiguous.",
"Promotion is valid only when entry identity, render integrity and evidence integrity are all materially confirmed."
]
},
{
title: "Downstream unlocks",
items: [
"A complete Panel Manifest unlocks deterministic panel bootstrap.",
"It unlocks trustworthy consumption by panel tree, navigation spec, content index and blueprint-side reading.",
"It unlocks consistent interpretation of the panel entry layer across Documentation Hub and Operator Panel surfaces.",
"It unlocks safer downstream validation because the entry artifact is no longer ambiguous."
]
},
{
title: "Non-promotable states",
items: [
"A manifest that is selectable but not identity-stable is not promotable.",
"A manifest that renders through the wrong payload is not promotable.",
"A manifest that only appears structurally complete through cached UI behavior is not promotable.",
"A manifest that loses canonical support-role boundaries is not promotable.",
"A manifest that cannot keep architecture, contract and source views aligned is not promotable."
]
},
{
title: "Promotion evidence requirements",
items: [
"Promotion must be supported by observable UI behavior, stable routing and correct rendered content.",
"Promotion must be backed by hub registration, tree visibility and cross-view identity consistency.",
"Promotion must be proven from the served surface and not from assumed code intent.",
"Every completion or promotion claim must be evidenced by what the system actually resolves and renders."
]
},
{
title: "Completion and promotion exit rule",
items: [
"Panel Manifest completion and promotion are complete only when the entry artifact is materially present, canonically bound, tree-stable, payload-correct and trustworthy across architecture, contract and source views.",
"No downstream panel artifact may be promoted as reliable if Panel Manifest still operates under ambiguous routing, fallback behavior or unverified identity.",
"Completion and promotion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const leftHtml = [
renderStructuredCard("Prerequisites", prerequisitesBuckets),
renderStructuredCard("Configuration", configurationBuckets),
renderStructuredCard("Observable Evidence", observableEvidenceBuckets),
renderStructuredCard("Completion & Promotion", completionPromotionBuckets)
].join("");
const installationBuckets = [
{
title: "Definition and installation role",
items: [
"Panel Manifest installation defines the set of material conditions required for the Panel entry manifest to exist, be readable, be structurally usable and participate in deterministic panel bootstrap.",
"Installation here does not mean generic server setup. It means making the Panel Manifest materially present as a machine-readable entry artifact inside the Devon documentation and panel surface.",
"The manifest must be installed as part of the panel-facing documentary layer, not as sovereign architecture and not as isolated UI text.",
"Its installation role is to establish a stable entry surface that downstream panel tree, navigation, content mapping and contract reading can consume safely."
]
},
{
title: "Document materialization requirements",
items: [
"Panel Manifest must exist as a real document bound to Phase 01 overview_scope.",
"Its file identity, path, phase, layer and document id must be materially registered in the hub structure.",
"The manifest must be readable through the documentation surface and discoverable from the architecture tree.",
"The document must be positioned as panel entry support and must not appear detached from the canonical overview structure."
]
},
{
title: "Canonical binding installation",
items: [
"master_architecture_index must already exist as sovereign architectural root before Panel Manifest installation is considered valid.",
"Panel Manifest must be structurally linked to master_architecture_index, project scope and deployment order rather than installed as a free-floating UI artifact.",
"Its installation must preserve sovereign/support separation.",
"The manifest must inherit meaning from the canonical root and must never redefine architectural truth locally."
]
},
{
title: "Hub and tree installation",
items: [
"Panel Manifest must be registered inside hub_index.json under overview_scope.",
"It must appear in the left architecture tree with correct label, type and category placement.",
"Its selection must resolve to the correct document identity in the render flow.",
"Its architecture view, contract view and source view must remain bound to the same document identity."
]
},
{
title: "Panel bootstrap installation",
items: [
"The manifest must be installable as a deterministic entry point for panel bootstrap.",
"Downstream panel-side reading must be able to start from this manifest without ambiguity.",
"The manifest must support initial binding for panel tree, navigation, content index and blueprint-side reading.",
"No downstream panel bootstrap should depend on scattered assumptions once the manifest is installed."
]
},
{
title: "Rendering and UI installation",
items: [
"Panel Manifest must render through the same architecture scaffold used by the category model.",
"Its structured cards must remain readable in architecture mode.",
"Its content must be projectable into the Documentation Hub without collapsing into the fallback summary view.",
"Its rendering path must remain deterministic when selected from the UI."
]
},
{
title: "Source and contract installation",
items: [
"The manifest must support contract projection as a machine-readable panel entry document.",
"Its source view must reflect the real underlying source rather than a synthetic local substitute.",
"Its contract view must remain consistent with the same document registration seen in architecture mode.",
"The installation is invalid if architecture, contract and source routes diverge in identity."
]
},
{
title: "Dependency installation gates",
items: [
"Canonical registration must exist before Panel Manifest installation can be trusted.",
"Hub registration must exist before UI selection can be trusted.",
"UI selection integrity must exist before architecture rendering can be trusted.",
"Document identity stability must exist before downstream panel contracts can be trusted."
]
},
{
title: "Failure-sensitive installation conditions",
items: [
"If the manifest exists in code but is not reachable in the tree, installation is incomplete.",
"If the manifest is reachable in the tree but resolves to the wrong payload, installation is invalid.",
"If the manifest renders only through fallback summary, installation is incomplete.",
"If the manifest loses canonical linkage, installation is invalid even if the UI still renders."
]
},
{
title: "Installation exit rule",
items: [
"Panel Manifest installation is complete only when the document is materially present, canonically bound, tree-selectable, architecturally renderable and identity-stable across architecture, contract and source views.",
"No downstream panel artifact may be treated as installation-ready if the Panel Manifest entry layer is still ambiguous or fallback-driven.",
"Installation completion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const validationBuckets = [
{
title: "Definition and validation role",
items: [
"Panel Manifest validation defines the evidence-based checks required to confirm that the manifest is structurally correct, canonically bound and operationally trustworthy as the panel entry surface.",
"Validation here does not judge visual preference. It verifies identity integrity, route integrity, source integrity and cross-view consistency.",
"Its role is to prove that the selected Panel Manifest is the real registered artifact and not a fallback, alias or displaced payload.",
"A valid Panel Manifest must remain verifiable across architecture, contract and source modes."
]
},
{
title: "Identity validation",
items: [
"The document selected in the tree must resolve to panel_manifest and not to another overview_scope artifact.",
"Its document id, label, path, phase and layer must remain stable during selection and rendering.",
"The same artifact must be observed across architecture view, contract view and source view.",
"Validation fails if the UI selection path resolves to a mismatched document identity."
]
},
{
title: "Canonical linkage validation",
items: [
"Panel Manifest must remain subordinate to master_architecture_index sovereignty.",
"Its role as support-level panel entry artifact must remain explicit.",
"Its linkage to project scope and deployment order must remain materially traceable.",
"Validation fails if the manifest appears structurally detached from the canonical overview roots."
]
},
{
title: "Render-path validation",
items: [
"Architecture mode must render the custom Panel Manifest architecture payload, not an unrelated structured category payload.",
"Contract mode must describe the same registered Panel Manifest artifact.",
"Source mode must expose the real underlying source of Panel Manifest.",
"Validation fails if any mode falls back to the wrong document or if architecture mode depends on the wrong sourceMeta branch."
]
},
{
title: "Tree and selection validation",
items: [
"Panel Manifest must appear in the correct category position inside the architecture tree.",
"A click on Panel Manifest must keep the selected document stable across re-render.",
"Mode switching must not silently redirect the user to Master Architecture Index or another sibling document.",
"Validation fails if tree selection is visually correct but operationally resolves to another payload."
]
},
{
title: "Content integrity validation",
items: [
"The architecture cards shown under Panel Manifest must correspond to Panel Manifest content and not inherited text from another document.",
"Overview, Prerequisites, Installation, Configuration and downstream cards must remain context-consistent with Panel Manifest.",
"The manifest must not render stale content cached from a previous selection.",
"Validation fails if the visible text belongs to another document context."
]
},
{
title: "Cross-view consistency validation",
items: [
"Architecture, contract and source views must describe the same artifact from different angles.",
"No view may invent identity, dependency or role that is absent from the registered document.",
"Cross-view consistency must remain stable after reload, reselection and mode switching.",
"Validation fails if one view is correct but another diverges in identity or meaning."
]
},
{
title: "Fallback and error-state validation",
items: [
"The Panel Manifest architecture route must not depend on fallback summary unless there is a real source-load failure.",
"If source loading fails, the error state must still preserve the correct document identity.",
"A rendered fallback must never masquerade as successful validation.",
"Validation fails if the UI looks stable but the underlying route is fallback-driven or source-broken."
]
},
{
title: "Evidence requirements",
items: [
"Validation must be grounded in observable UI behavior and observable document routing.",
"Validation must be supported by file existence, tree registration, route stability and mode consistency.",
"No validation claim may be based on inference, expectation or visual guess alone.",
"Every PASS condition must be backed by real evidence from the served surface or underlying registered artifact."
]
},
{
title: "Validation exit rule",
items: [
"Panel Manifest validation is complete only when identity, linkage, tree routing, render path, source exposure and cross-view consistency are all materially confirmed.",
"No downstream panel artifact may be treated as trustworthy if Panel Manifest validation still depends on ambiguous selection or unverified routing.",
"Validation completion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const failureModesBuckets = [
{
title: "Definition and recovery role",
items: [
"Panel Manifest failure modes and recovery define the invalid states that break the manifest as a trustworthy panel entry surface and the recovery actions required to restore deterministic panel bootstrap.",
"Failure here is not limited to crash. It includes wrong document routing, fallback contamination, identity drift, stale payload reuse and cross-view inconsistency.",
"Recovery exists to restore the correct manifest identity, canonical linkage and render path without inventing local truth.",
"A recovered state is valid only when the manifest returns to evidence-based stability across architecture, contract and source views."
]
},
{
title: "Identity failure modes",
items: [
"Panel Manifest may appear selected in the tree while another document payload is actually rendered.",
"The manifest may resolve with the wrong document id, wrong path or wrong architectural context.",
"A stale selection state may visually preserve the label while operationally switching to another artifact.",
"Recovery requires proving the selected payload is again bound to panel_manifest and not to any sibling document."
]
},
{
title: "Render-path failure modes",
items: [
"Architecture mode may fall back to a summary or to an inherited structured payload that does not belong to Panel Manifest.",
"The UI may render content from Master Architecture Index or another overview_scope artifact while Panel Manifest remains selected.",
"Source-load failure may silently degrade into a misleading render path.",
"Recovery requires restoring the direct architecture path so the custom Panel Manifest payload is the one actually rendered."
]
},
{
title: "Canonical linkage failure modes",
items: [
"Panel Manifest may remain visible while losing its subordinate linkage to master_architecture_index.",
"The manifest may drift from project scope or deployment order anchoring.",
"Support-level role may become blurred and appear as if the manifest were redefining architectural authority.",
"Recovery requires re-establishing sovereign/support separation and re-binding the manifest to the canonical overview roots."
]
},
{
title: "Tree and selection failure modes",
items: [
"The tree may show Panel Manifest in the right place while click resolution points to the wrong payload.",
"Mode switching may silently redirect the user away from Panel Manifest.",
"Reload or reselection may destabilize the active document identity.",
"Recovery requires restoring deterministic selection so tree label, selected doc and rendered payload all converge."
]
},
{
title: "Cross-view failure modes",
items: [
"Architecture, contract and source views may diverge in identity or meaning.",
"Contract view may describe one artifact while architecture mode renders another.",
"Source view may expose a different backing document than the one used by architecture mode.",
"Recovery requires re-aligning all three modes to the same registered Panel Manifest artifact."
]
},
{
title: "Content contamination failure modes",
items: [
"Panel Manifest may display inherited content from another document after updates or reselection.",
"Cached or previously loaded text may survive and contaminate the visible architecture cards.",
"Panel-specific cards may show valid structure but invalid content origin.",
"Recovery requires flushing the contaminated render path and confirming that visible text now belongs to Panel Manifest context only."
]
},
{
title: "Recovery actions",
items: [
"Re-select Panel Manifest from the tree and confirm the selected document remains stable across mode switches.",
"Force the direct architecture render path when manifest-specific architecture content must bypass inherited structured payload selection.",
"Verify that hub registration, tree selection and rendered payload identity still point to panel_manifest.",
"Re-check architecture, contract and source views until all three describe the same artifact.",
"Treat any fallback-driven or cross-document state as invalid until evidence proves recovery is complete."
]
},
{
title: "Recovery evidence requirements",
items: [
"Recovery is valid only when the manifest is again materially reachable, correctly selected and rendered from the correct payload.",
"The recovered state must be observable in UI behavior and not merely assumed from code edits.",
"The visible cards must show Panel Manifest-specific content after recovery.",
"Architecture, contract and source routes must all confirm the same restored identity."
]
},
{
title: "Failure modes and recovery exit rule",
items: [
"Panel Manifest failure and recovery handling is complete only when all known invalid routing, identity, fallback and cross-view divergence states are detectable and recoverable through evidence-based actions.",
"No downstream panel artifact may be treated as trustworthy if Panel Manifest recovery still depends on unverified assumptions.",
"Failure and recovery completion for Panel Manifest must remain evidence-based and subordinate to master_architecture_index sovereignty."
]
}
];
const rightHtml = [
renderStructuredCard("Installation", installationBuckets),
renderStructuredCard("Validation", validationBuckets),
renderStructuredCard("Failure Modes & Recovery", failureModesBuckets)
].join("");
return {
kind: "html",
content: overviewHtml + `