Add exhaustive Solidity contract interaction atlas

docs/charts/diagramSpecs.json

@@ -10851,6 +10851,13 @@
 		"nodes": [],
 		"width": 1120
 	},
+	"fig-complete-contract-atlas": {
+		"ariaDescription": "Six separated regions inventory Zoltar, Statoblast deployment, Statoblast runtime, Statoblast implementation boundaries, infrastructure and imported OpenOracle code, and test-only Solidity declarations. Every Solidity contract, abstract contract, interface, and library in the repository appears once in its owning region; two type-only modules also appear. The register contains 394 relationships grouped into 376 ordered source-target routes. The chart defaults to a clearer 96-route protocol-flow layer; controls reveal type structure, source references, test exercise, or all routes without moving or removing components. Eighteen routes combine two relationship types; their tooltips list both types and meanings. Solid, long-dash, dot–dash, and short-dash arrows respectively show runtime calls, asset-bearing calls, deployments, and delegatecalls. Dashed or dotted arrows show inheritance, interface implementation, structural compatibility, library or type use, direct source references, and test-only exercise. A dark patterned arrow marks multiple relationship types. Production target groups are repeated inside the test region to prevent test edges from crossing the full chart.",
+		"ariaLabel": "Complete Zoltar and Statoblast Solidity contract and relationship atlas",
+		"height": 2480,
+		"nodes": [],
+		"width": 1800
+	},
 	"fig-liquidation-health-curve": {
 		"ariaDescription": "Required REP backing rises linearly with the REP per ETH price, while unlocked REP stays fixed. Crossing the available-REP line makes the selected vault liquidatable.",
 		"ariaLabel": "Vault backing requirement and liquidation threshold across REP per ETH prices",

docs/contract-interactions.html

@@ -14,9 +14,12 @@ <h1>Contract Interaction Map</h1>
 				<p>
 					This map connects the primary deployed Zoltar registry and Statoblast
 					market contracts. It emphasizes contract-to-contract calls and asset
-					movement, not every public user entrypoint. Factory-only deployment
-					workers, delegate modules, event emitters, and compatibility contracts
-					are summarized separately so the runtime path stays legible.
+					movement, not every public user entrypoint. The first chart keeps that
+					primary runtime path legible. The separate
+					<a href="#complete-atlas">complete contract atlas</a>
+					then expands every Solidity declaration, including factories, delegates,
+					bases, interfaces, libraries, infrastructure, imported compatibility
+					code, and test-only contracts.
 				</p>
 				<p class="security-assumption-ref">
 					<strong>Related reading:</strong>
@@ -39,6 +42,10 @@ <h2>Primary Interaction Flow</h2>
 					enter through several of these contracts, but are omitted so the plot
 					can focus on contract-to-contract boundaries.
 				</p>
+				<p data-primary-flow-boundary>
+					This intentionally compact view contains exactly 12 unique components
+					and 19 interactions; it is not exhaustive.
+				</p>
 				<figure class="diagram diagram-wide" id="fig-contract-interaction-map">
 					<div class="plot-chart" data-plot-chart="fig-contract-interaction-map" data-plot-width="1120" data-plot-height="880" role="img" aria-label="Zoltar and Statoblast contract interactions grouped into deployment, runtime, and fork phases"><span class="plot-chart-fallback">Contract interactions are separated into three phases. During deployment, the pool factory validates question and universe data before deploying the pool, share token, and price coordinator. During runtime, the pool manages claims and escalation escrow while guarded actions travel through the price coordinator and OpenOracle. During a fork, the share token enters the pool forker, which snapshots escalation, migrates REP through a proxy, creates and migrates child pools, and repairs backing through the truth auction.</span></div>
 					<p class="diagram-caption">
@@ -48,13 +55,20 @@ <h2>Primary Interaction Flow</h2>
 						Blue nodes are registries or oracle infrastructure, green nodes hold
 						market state and claims, red marks local resolution, and gold marks
 						deployment or fork coordination. Short edge labels state the action;
-						the table below supplies its exact contract-level meaning.
+						the <a href="#edges">primary interaction table</a> supplies its exact
+						contract-level meaning.
 					</p>
 				</figure>
 			</section>
 
 			<section id="edges">
-				<h2>What Each Arrow Means</h2>
+				<h2>What Each Primary-Flow Arrow Means</h2>
+				<p>
+					These 19 rows explain the arrows in the
+					<a href="#overview">Primary Interaction Flow</a>. The exhaustive atlas
+					below has its own
+					<a href="#atlas-relationships">complete relationship register</a>.
+				</p>
 				<div class="table-scroll" tabindex="0" role="region" aria-label="Contract interaction details">
 					<table>
 						<thead>
@@ -218,10 +232,11 @@ <h2>Four Useful Reading Paths</h2>
 			</section>
 
 			<section id="supporting-contracts">
-				<h2>Supporting Contracts Not Expanded in the Plot</h2>
+				<h2>How the Primary Flow Compresses the Atlas</h2>
 				<p>
-					The diagram groups construction helpers and delegate modules behind the
-					deployed component whose behavior they implement:
+					The primary interaction flow groups construction helpers and delegate
+					modules behind the deployed component whose behavior they implement.
+					The complete atlas below expands every item in these groups:
 				</p>
 				<ul>
 					<li>
@@ -251,8 +266,190 @@ <h2>Supporting Contracts Not Expanded in the Plot</h2>
 				</ul>
 			</section>
 
+			<section id="complete-atlas">
+				<h2>Complete Solidity Contract Atlas</h2>
+				<p>
+					This chart exhaustively inventories Solidity declarations and their
+					direct relationships. Zoltar has its own region because it owns
+					questions, universes, and REP; Statoblast deployment, runtime, and
+					implementation components occupy three separate regions. Infrastructure
+					and imported OpenOracle code form another boundary, and test-only
+					contracts stay in a final region so they cannot be mistaken for deployed
+					protocol components.
+				</p>
+				<p>
+					The checked inventory contains 119 nodes and 394 relationships. Its
+					nodes cover all 117 Solidity declarations currently under
+					<code>solidity/contracts</code>: 76 production declarations and 41
+					test-only declarations, plus the two type-only modules
+					<code>EscalationGameTypes</code> and
+					<code>SecurityPoolForkerTypes</code>. Files that only re-export an
+					import do not create another declaration node.
+				</p>
+				<p>
+					Coverage is pair-based: every declaration that names an imported or
+					same-file contract, interface, library, or type module is linked. A
+					specific call, deployment, delegatecall, asset-bearing call,
+					inheritance, implementation, library/type use, or test edge replaces the
+					generic source reference. The register keeps all 394 relationship rows
+					separate. The plot groups them into 376 ordered source-target routes:
+					18 routes carry two relationship types, so their combined style and
+					tooltip list both meanings. Repeated uses of the same type and pair
+					aggregate; distinct types and explicit low-level boundaries remain
+					separate register rows. A compiler-AST check promotes actual contract
+					and interface member invocations, library calls and constants, using
+					directives, and test-helper invocations out of the generic layer. A
+					deployment, inheritance, implementation, or type-use relationship on
+					the same pair does not stand in for a runtime call; the register and
+					tooltip retain both meanings. Invocation analysis follows direct calls
+					and typed members encoded for ordinary low-level calls; it excludes
+					selector-only references and members encoded for separately classified
+					delegatecalls. The generic layer therefore contains only reference-only
+					pairs. The chart keeps all 119 components fixed while one relationship
+					layer is selected; choose <strong>All routes</strong> for the complete
+					overlay.
+				</p>
+				<fieldset class="contract-atlas-controls" data-contract-atlas-controls hidden>
+					<legend>Relationship layer</legend>
+					<div class="contract-atlas-view-options" role="group" aria-label="Contract atlas relationship layer">
+						<button type="button" data-contract-atlas-view="protocol" aria-pressed="true">
+							<strong>Protocol flow</strong>
+							<span data-contract-atlas-view-count="protocol"></span>
+						</button>
+						<button type="button" data-contract-atlas-view="structure" aria-pressed="false">
+							<strong>Type structure</strong>
+							<span data-contract-atlas-view-count="structure"></span>
+						</button>
+						<button type="button" data-contract-atlas-view="references" aria-pressed="false">
+							<strong>Source references</strong>
+							<span data-contract-atlas-view-count="references"></span>
+						</button>
+						<button type="button" data-contract-atlas-view="tests" aria-pressed="false">
+							<strong>Test exercise</strong>
+							<span data-contract-atlas-view-count="tests"></span>
+						</button>
+						<button type="button" data-contract-atlas-view="all" aria-pressed="false">
+							<strong>All routes</strong>
+							<span data-contract-atlas-view-count="all"></span>
+						</button>
+					</div>
+					<p class="contract-atlas-view-status" data-contract-atlas-status aria-live="polite"></p>
+				</fieldset>
+				<ul class="contract-atlas-legend" aria-label="Complete contract atlas line styles">
+					<li><span class="atlas-line atlas-line-call" aria-hidden="true"></span><strong>Runtime call — solid</strong></li>
+					<li><span class="atlas-line atlas-line-assets" aria-hidden="true"></span><strong>Asset-bearing call — long dash</strong></li>
+					<li><span class="atlas-line atlas-line-deploy" aria-hidden="true"></span><strong>Deployment — dot–dash</strong></li>
+					<li><span class="atlas-line atlas-line-delegate" aria-hidden="true"></span><strong>Delegatecall — short dash</strong></li>
+					<li><span class="atlas-line atlas-line-source" aria-hidden="true"></span><strong>Inheritance, interface, compatibility, or library/type use</strong></li>
+					<li><span class="atlas-line atlas-line-reference" aria-hidden="true"></span><strong>Direct source reference</strong></li>
+					<li><span class="atlas-line atlas-line-test" aria-hidden="true"></span><strong>Test-only exercise</strong></li>
+					<li><span class="atlas-line atlas-line-multiple" aria-hidden="true"></span><strong>Multiple relationship types</strong></li>
+				</ul>
+				<figure class="diagram diagram-atlas" id="fig-complete-contract-atlas">
+					<div
+						class="diagram-scroll"
+						tabindex="0"
+						role="region"
+						aria-label="Scrollable figure: Complete Zoltar and Statoblast Solidity contract and relationship atlas"
+					>
+						<div
+							class="plot-chart"
+							data-plot-chart="fig-complete-contract-atlas"
+							data-plot-width="1800"
+							data-plot-height="2480"
+							role="img"
+							aria-label="Complete Zoltar and Statoblast Solidity contract and relationship atlas"
+						>
+							<span class="plot-chart-fallback"
+								>The complete atlas separates Zoltar from Statoblast deployment,
+								runtime, and implementation code. Additional regions contain
+								deployment infrastructure, imported OpenOracle and compatibility
+								code, and every test-only Solidity declaration. Solid, long-dash,
+								dot–dash, and short-dash arrows respectively represent runtime
+								calls, asset-bearing calls, deployments, and delegatecalls;
+								dashed or dotted arrows represent inheritance, interfaces,
+								libraries, type modules, direct source references, or test-only
+								exercise. A dark patterned arrow combines multiple relationship
+								types for the same ordered contract pair.</span
+							>
+						</div>
+					</div>
+					<p class="diagram-caption">
+						<span class="figure-label">Complete Contract Atlas</span>Every
+						contract, abstract contract, interface, and library declaration has
+						one inventory node. Test edges terminate at repeated production
+						gateway groups inside the test region to avoid crossing the entire
+						plot; the relationship register preserves each exact production
+						target. The default protocol-flow layer shows 96 routes; the layer
+						controls expose every one of the 376 routes while keeping all 119
+						components fixed. Mechanical reconciliation against the Solidity
+						tree covers every direct source edge, and all 394 meanings remain in
+						the route tooltips and register. The component inventory provides an
+						exact textual entry for every node, including isolated declarations
+						that have no active in-repository relationship under the rule above.
+					</p>
+				</figure>
+				<details class="contract-atlas-register contract-atlas-node-register">
+					<summary>Complete 119-component inventory</summary>
+					<p>
+						This inventory preserves each component’s declaration kind, owning
+						region, and Solidity source path independently of chart hover or
+						relationship coverage.
+					</p>
+					<div class="table-scroll" tabindex="0" role="region" aria-label="Complete Solidity component inventory">
+						<table>
+							<thead>
+								<tr>
+									<th>Component</th>
+									<th>Kind</th>
+									<th>Region</th>
+									<th>Source</th>
+								</tr>
+							</thead>
+							<tbody data-contract-atlas-node-table>
+								<tr>
+									<td colspan="4">The generated component inventory requires JavaScript; the figure fallback summarizes its regions and component kinds.</td>
+								</tr>
+							</tbody>
+						</table>
+					</div>
+				</details>
+				<details class="contract-atlas-register" id="atlas-relationships">
+					<summary>Complete relationship register</summary>
+					<p>
+						Arrows point from the initiator, child, implementation, or test
+						double to the receiver, parent, dependency, or production target.
+						For an asset-bearing call, this is code/dependency direction rather
+						than a claim that the edge target receives the asset; its meaning
+						states the actual sender → recipient path.
+					</p>
+					<div class="table-scroll" tabindex="0" role="region" aria-label="Complete Solidity relationship register">
+						<table>
+							<thead>
+								<tr>
+									<th>Source</th>
+									<th>Target</th>
+									<th>Relationship</th>
+									<th>Meaning</th>
+								</tr>
+							</thead>
+							<tbody data-contract-atlas-table>
+								<tr>
+									<td colspan="4">The generated relationship register requires JavaScript; the figure fallback summarizes its edge types.</td>
+								</tr>
+							</tbody>
+						</table>
+					</div>
+				</details>
+			</section>
+
 			<section id="sources">
-				<h2>Source Contracts</h2>
+				<h2>Primary Flow Source Contracts</h2>
+				<p>
+					These are the entry sources for the compact primary flow. Each atlas
+					node records its exact source path, and the atlas inventory is checked
+					directly against every Solidity declaration in the source tree.
+				</p>
 				<ul>
 					<li><a href="../solidity/contracts/ZoltarQuestionData.sol"><code>ZoltarQuestionData.sol</code></a></li>
 					<li><a href="../solidity/contracts/Zoltar.sol"><code>Zoltar.sol</code></a> and <a href="../solidity/contracts/ReputationToken.sol"><code>ReputationToken.sol</code></a></li>

docs/docsReader.js

@@ -70,7 +70,7 @@ const documentGroups = [
 			{
 				path: 'contract-interactions.html',
 				title: 'Contract interaction map',
-				description: 'How deployed contracts call, deploy, and move assets between one another.',
+				description: 'Primary runtime flow and exhaustive Solidity declaration and checked relationship atlas.',
 			},
 			{
 				path: 'escalation-game-architecture.html',