amalfa 1.0.1 → 1.0.3

package/src/resonance/transform/cda.ts

@@ -1,393 +0,0 @@
-#!/usr/bin/env bun
-
-/**
- * CDA/CL Transformation Pipeline
- *
- * Transforms raw CDA and Lexicon into enriched intermediate structure
- * with keyword extraction and candidate relationship generation.
- */
-
-import { join } from "node:path";
-import { SemanticMatcher } from "@src/core/SemanticMatcher";
-import type {
-	CandidateRelationship,
-	EnrichedCdaDocument,
-	EnrichedCdaEntry,
-	EnrichedLexiconConcept,
-	EnrichedLexiconDocument,
-} from "@src/resonance/types/enriched-cda";
-import settings from "@/polyvis.settings.json";
-
-// Simple keyword extraction (can be enhanced later)
-function extractKeywords(text: string): string[] {
-	if (!text) return [];
-
-	// Remove common words, extract significant terms
-	const stopWords = new Set([
-		"the",
-		"a",
-		"an",
-		"and",
-		"or",
-		"but",
-		"in",
-		"on",
-		"at",
-		"to",
-		"for",
-		"of",
-		"with",
-		"by",
-		"from",
-		"as",
-		"is",
-		"are",
-		"was",
-		"were",
-		"be",
-		"been",
-		"being",
-		"have",
-		"has",
-		"had",
-		"do",
-		"does",
-		"did",
-		"will",
-		"would",
-		"should",
-		"could",
-		"may",
-		"might",
-		"must",
-		"can",
-		"this",
-		"that",
-		"these",
-		"those",
-		"it",
-		"its",
-	]);
-
-	const words = text
-		.toLowerCase()
-		.replace(/[^a-z0-9\s-]/g, " ")
-		.split(/\s+/)
-		.filter((w) => w.length > 3 && !stopWords.has(w));
-
-	// Return unique keywords
-	return [...new Set(words)];
-}
-
-// Match keywords to lexicon concepts
-function matchKeywordsToConcepts(
-	keywords: string[],
-	concepts: EnrichedLexiconConcept[],
-): CandidateRelationship[] {
-	const relationships: CandidateRelationship[] = [];
-
-	for (const keyword of keywords) {
-		for (const concept of concepts) {
-			// Check title match
-			const titleMatch = concept.title.toLowerCase().includes(keyword);
-			const aliasMatch = concept.aliases.some((alias) =>
-				alias.toLowerCase().includes(keyword),
-			);
-			const keywordMatch = concept.extracted_keywords.includes(keyword);
-
-			if (titleMatch || aliasMatch || keywordMatch) {
-				// Calculate confidence based on match type
-				let confidence = 0.5; // Base confidence for keyword match
-				if (titleMatch) confidence = 0.85;
-				if (aliasMatch) confidence = 0.75;
-
-				relationships.push({
-					type: "MENTIONS",
-					target: concept.id,
-					confidence,
-					source: "keyword_match",
-				});
-			}
-		}
-	}
-
-	// Deduplicate and keep highest confidence
-	const deduped = new Map<string, CandidateRelationship>();
-	for (const rel of relationships) {
-		const existing = deduped.get(rel.target);
-		if (!existing || rel.confidence > existing.confidence) {
-			deduped.set(rel.target, rel);
-		}
-	}
-
-	return Array.from(deduped.values());
-}
-
-// Parse explicit tags from CDA entries
-function parseExplicitTags(
-	tags: string[],
-	concepts: EnrichedLexiconConcept[],
-): CandidateRelationship[] {
-	const relationships: CandidateRelationship[] = [];
-
-	for (const tag of tags) {
-		// Match pattern: [TYPE: Target]
-		const match = tag.match(/\[([A-Z_]+):\s*([^\]]+)\]/);
-		if (!match) continue;
-
-		const typeStr = match[1];
-		const targetStr = match[2];
-		if (!typeStr || !targetStr) continue;
-
-		const target = targetStr.trim().toLowerCase().replace(/\s+/g, "-");
-
-		// Map tag types to relationship types
-		const typeMap: Record<string, CandidateRelationship["type"]> = {
-			SUBSTRATE_ISSUE: "ADDRESSES",
-			IMPLEMENTS: "IMPLEMENTS",
-			GUIDED_BY: "GUIDED_BY",
-			RELATED_TO: "RELATED_TO",
-			REQUIRES: "REQUIRES",
-			ENABLES: "ENABLES",
-		};
-
-		const relType = typeMap[typeStr] || "RELATED_TO";
-
-		// Try to find matching concept
-		const concept = concepts.find(
-			(c) =>
-				c.id.includes(target) ||
-				c.title.toLowerCase().replace(/\s+/g, "-") === target ||
-				c.aliases.some((a) => a.toLowerCase().replace(/\s+/g, "-") === target),
-		);
-
-		if (concept) {
-			relationships.push({
-				type: relType,
-				target: concept.id,
-				confidence: 1.0, // Explicit tags have high confidence
-				source: "explicit_tag",
-			});
-		} else {
-			console.warn(
-				`⚠️  Tag target not found in lexicon: ${targetStr} (from tag: ${tag})`,
-			);
-		}
-	}
-
-	return relationships;
-}
-
-async function main() {
-	console.log("🔄 CDA/CL Transformation Pipeline");
-	console.log("═".repeat(60));
-
-	const root = process.cwd();
-
-	// Load source files
-	console.log("\n📂 Loading source files...");
-	const lexiconPath = join(root, settings.paths.sources.persona.lexicon);
-	const cdaPath = join(root, settings.paths.sources.persona.cda);
-
-	const lexiconData = await Bun.file(lexiconPath).json();
-	const cdaData = await Bun.file(cdaPath).json();
-
-	// Transform Lexicon
-	console.log("\n🧠 Transforming Lexicon...");
-	const lexiconConcepts = (
-		Array.isArray(lexiconData) ? lexiconData : lexiconData.concepts
-	) as EnrichedLexiconConcept[];
-
-	const enrichedConcepts: EnrichedLexiconConcept[] = lexiconConcepts.map(
-		(c) => ({
-			id: c.id,
-			type: "concept",
-			title: c.title,
-			description: c.description || c.title,
-			category: c.category || "uncategorized",
-			extracted_keywords: extractKeywords(`${c.title} ${c.description || ""}`),
-			aliases: c.aliases || [],
-			meta: {
-				type: c.type,
-			},
-		}),
-	);
-
-	const enrichedLexicon: EnrichedLexiconDocument = {
-		version: "1.0.0",
-		generated_at: new Date().toISOString(),
-		source_file: lexiconPath,
-		concepts: enrichedConcepts,
-		stats: {
-			total_concepts: enrichedConcepts.length,
-			total_keywords_extracted: enrichedConcepts.reduce(
-				(sum, c) => sum + c.extracted_keywords.length,
-				0,
-			),
-		},
-	};
-
-	console.log(`   ✅ ${enrichedConcepts.length} concepts enriched`);
-	console.log(
-		`   ✅ ${enrichedLexicon.stats.total_keywords_extracted} keywords extracted`,
-	);
-
-	// Transform CDA
-	console.log("\n📋 Transforming CDA...");
-	const cdaEntries: EnrichedCdaEntry[] = [];
-
-	// Initialize Semantic Matcher (mgrep wrapper)
-	const semanticMatcher = new SemanticMatcher();
-	console.log("   🤖 Initialized Semantic Matcher");
-	let totalSemanticRels = 0;
-
-	for (const section of cdaData.directives) {
-		for (const entry of section.entries) {
-			const keywords = extractKeywords(entry.definition || "");
-			const explicitRels = parseExplicitTags(
-				entry.tags || [],
-				enrichedConcepts,
-			);
-			const keywordRels = matchKeywordsToConcepts(keywords, enrichedConcepts);
-
-			// Semantic Search Soft Links
-			const semanticRels: CandidateRelationship[] = [];
-
-			// Only run if we have a meaty definition to search with
-			if (entry.definition && entry.definition.length > 15) {
-				try {
-					// Search known documentation for semantic references
-					const docsPath = join(process.cwd(), settings.paths.docs.public);
-
-					const matches = await semanticMatcher.findCandidates(
-						entry.definition,
-						docsPath,
-					);
-
-					for (const match of matches) {
-						// Logic: If mgrep returns a match in the lexicon file,
-						// we need to identify WHICH concept that line belongs to.
-						// Naive approach: Basic text proximity or line number mapping.
-						// Better approach for MVP: Check if the matched content *contains* a concept title.
-
-						const relatedConcept = enrichedConcepts.find((c) =>
-							match.content.toLowerCase().includes(c.title.toLowerCase()),
-						);
-
-						if (relatedConcept) {
-							// Avoid dupes from keywords
-							if (!keywordRels.some((r) => r.target === relatedConcept.id)) {
-								semanticRels.push({
-									type: "RELATED_TO",
-									target: relatedConcept.id,
-									confidence: 0.65, // Lower than keyword, but significant
-									source: "semantic_search",
-								});
-								totalSemanticRels++;
-							}
-						}
-					}
-				} catch (_e) {
-					// Fail silently to normal flow
-				}
-			}
-
-			const candidateRels = [...explicitRels, ...keywordRels, ...semanticRels];
-
-			// Auto-validate high-confidence relationships
-			const validatedRels = candidateRels
-				.filter((rel) => rel.confidence >= 0.75) // High confidence threshold
-				.map((rel) => ({
-					type: rel.type,
-					target: rel.target,
-					source: rel.source,
-					validated: true,
-					validator:
-						rel.source === "explicit_tag" ? "auto" : "confidence_threshold",
-					validated_at: new Date().toISOString(),
-				}));
-
-			cdaEntries.push({
-				id: entry.id,
-				type: "directive",
-				title: entry.term || entry.id,
-				definition: entry.definition || "",
-				section: section.section,
-				explicit_tags: entry.tags || [],
-				extracted_keywords: keywords,
-				candidate_relationships: candidateRels,
-				validated_relationships: validatedRels,
-				meta: {},
-			});
-		}
-	}
-
-	const enrichedCda: EnrichedCdaDocument = {
-		version: "1.0.0",
-		generated_at: new Date().toISOString(),
-		source_files: {
-			cda: cdaPath,
-			lexicon: lexiconPath,
-		},
-		entries: cdaEntries,
-		stats: {
-			total_entries: cdaEntries.length,
-			entries_with_tags: cdaEntries.filter((e) => e.explicit_tags.length > 0)
-				.length,
-			total_explicit_tags: cdaEntries.reduce(
-				(sum, e) => sum + e.explicit_tags.length,
-				0,
-			),
-			total_keywords_extracted: cdaEntries.reduce(
-				(sum, e) => sum + e.extracted_keywords.length,
-				0,
-			),
-			total_candidate_relationships: cdaEntries.reduce(
-				(sum, e) => sum + e.candidate_relationships.length,
-				0,
-			),
-			total_validated_relationships: cdaEntries.reduce(
-				(sum, e) => sum + e.validated_relationships.length,
-				0,
-			),
-		},
-	};
-
-	console.log(`   ✅ ${cdaEntries.length} directives enriched`);
-	console.log(
-		`   ✅ ${enrichedCda.stats.total_keywords_extracted} keywords extracted`,
-	);
-	console.log(
-		`   ✅ ${enrichedCda.stats.total_candidate_relationships} candidate relationships generated`,
-	);
-	console.log(
-		`   ✅ ${enrichedCda.stats.total_validated_relationships} relationships validated`,
-	);
-
-	console.log(
-		`   ✅ ${enrichedCda.stats.total_validated_relationships} relationships validated`,
-	);
-	console.log(
-		`   ✨ ${totalSemanticRels} SWL (Semantic Soft Links) discovered`,
-	);
-
-	// Write output
-	console.log("\n💾 Writing enriched artifacts...");
-	const outputDir = join(root, ".resonance", "artifacts");
-	await Bun.write(
-		join(outputDir, "lexicon-enriched.json"),
-		JSON.stringify(enrichedLexicon, null, 2),
-	);
-	await Bun.write(
-		join(outputDir, "cda-enriched.json"),
-		JSON.stringify(enrichedCda, null, 2),
-	);
-
-	console.log(`   ✅ Lexicon: .resonance/artifacts/lexicon-enriched.json`);
-	console.log(`   ✅ CDA: .resonance/artifacts/cda-enriched.json`);
-
-	console.log(`\n${"═".repeat(60)}`);
-	console.log("✅ Transformation Complete");
-}
-
-main().catch(console.error);

package/src/utils/EnvironmentVerifier.ts

@@ -1,67 +0,0 @@
-import { existsSync } from "node:fs";
-import { resolve } from "node:path";
-import settings from "../../polyvis.settings.json";
-
-/**
- * EnvironmentVerifier
- *
- * Responsible for verifying that the runtime environment matches the
- * expectations set in polyvis.settings.json.
- *
- * Usage:
- * await EnvironmentVerifier.verifyOrExit();
- */
-export const EnvironmentVerifier = {
-	async verifyOrExit(): Promise<void> {
-		const errors: string[] = [];
-		const cwd = process.cwd();
-
-		console.error(`🛡️  [Env] Verifying filesystem context in: ${cwd}`);
-
-		// 1. Verify Database Directory
-		const dbPath = settings.paths.database.resonance;
-		const dbDir = resolve(cwd, dbPath, "..");
-		if (!existsSync(dbDir)) {
-			errors.push(`Database directory missing: ${dbDir}`);
-		}
-
-		// 2. Verify Source Directories
-		// We iterate over the 'sources' config to ensure target folders exist
-		const experienceSources = settings.paths.sources.experience;
-		for (const source of experienceSources) {
-			const absPath = resolve(cwd, source.path);
-			if (!existsSync(absPath)) {
-				console.warn(
-					`   ⚠️  Optional source directory missing: ${source.path} (created automatically by some tools, but worth noting)`,
-				);
-				// We don't hard fail on standard folders, as they might be empty/missing in a fresh repo.
-				// But specifically for 'docs' or critical ones we might want to be stricter.
-				// For now, we WARN.
-			}
-		}
-
-		// 3. Verify Static Assets (Lexicon/CDA)
-		const lexiconPath = resolve(cwd, settings.paths.sources.persona.lexicon);
-		if (!existsSync(lexiconPath)) {
-			errors.push(`Critical Artifact missing: Lexicon (${lexiconPath})`);
-		}
-
-		const cdaPath = resolve(cwd, settings.paths.sources.persona.cda);
-		if (!existsSync(cdaPath)) {
-			errors.push(`Critical Artifact missing: CDA (${cdaPath})`);
-		}
-
-		if (errors.length > 0) {
-			console.error("\n❌ Environment Verification Failed:");
-			errors.forEach((e) => {
-				console.error(`   - ${e}`);
-			});
-			console.error(
-				"\nPlease ensure you are running from the project root and all assets are present.",
-			);
-			process.exit(1);
-		}
-
-		console.error("   ✅ Environment Verified.");
-	},
-};

package/substack/substack-playbook-1.md

@@ -1,95 +0,0 @@
-This is an exciting moment. Launching a Substack is effectively "shipping" your philosophy, not just your code.
-
-Based on my analysis of the **PolyVis repository**—specifically the focus on "Structural Information Engineering," "Zero Magic" design, and the "Ctx" persona—your project has a very distinct voice. It is rigorous, slightly contrarian (rejecting modern complexity), and deeply focused on **order**.
-
-Here is a strategy and a draft for your first post.
-
-### The Strategy: "The Manifesto" Approach
-
-Substack readers love a strong point of view. Since PolyVis is about **reducing entropy** and **finding structure**, your first post should define the *problem* (AI creates a mess/hairball) and your *solution* (PolyVis/Graphs).
-
-**Key Themes from your Repo to highlight:**
-1.  **"Stuff into Things"**: The core act of Mentation.
-2.  **The "Hairball" Problem**: Vector databases give you vibes; Graphs give you maps.
-3.  **Low-Tech Defence**: Why you built this with Alpine/Bun/SQLite instead of a heavy React stack.
-
----
-
-### First Draft: PolyVis Substack Post #1
-
-**Headline:** Don't Just Search the Machine. Map It.
-**Subtitle:** Why I built PolyVis to turn AI "stuff" into structural "things."
-
-***
-
-We are drowning in context.
-
-Every time we interact with an LLM, we generate a stream of brilliance, hallucinations, code snippets, and philosophical debates. But the moment the chat window closes, that intelligence evaporates. It becomes a "hairball"—a tangled mess of unstructured text.
-
-We have access to the most powerful intelligence in human history, but we lack the map to navigate it.
-
-**Hello. I am pjsvis.**
-
-I am a builder focused on **Structural Information Engineering**. For the past few months, I have been working on a project called **PolyVis**.
-
-### The Problem: The "Vector Bottleneck"
-
-The current industry obsession is RAG (Retrieval Augmented Generation). We take our documents, chop them into chunks, throw them into a vector database, and hope the AI can "fish" out the right answer based on similarity.
-
-It works... mostly. But it’s probabilistic. It guesses. It gives you "fuzzy vibes" rather than hard facts.
-
-I wanted something deterministic. I didn't want to just *search* my knowledge base; I wanted to *see* it. I wanted to see how a "Directive" connects to a "Heuristic," and how that Heuristic informs a specific piece of "Code."
-
-### Enter PolyVis
-
-PolyVis is a **Neuro-Symbolic Graph Visualizer**.
-
-That sounds fancy, but the philosophy is simple: **Turn "Stuff" (unstructured inputs) into "Things" (coherent, connected objects).**
-
-It is a tool that sits on top of my AI interactions. It creates a "Psychogeography" of the code—a map where I can see the highways, the ghettos, and the fortresses of my project.
-
-
-### The "Zero Magic" Philosophy
-
-PolyVis isn't just about *what* it does, but *how* it's built.
-
-In an era of bloat, PolyVis follows the **Principle of Effective Low-Tech Defence**.
-* **No Build Step:** It runs on standard web technologies.
-* **No React:** It uses Alpine.js for lightweight reactivity.
-* **Local First:** It runs on a local SQLite database (via WASM) because your data belongs to you, not a cloud provider.
-
-I call this **"Zero Magic."** If I can't explain how a pixel got to the screen without referencing a black-box library, it doesn't belong in the stack.
-
-### What to Expect from This Substack
-
-I am using this space to document the engineering and philosophy behind PolyVis. Future posts will cover:
-
-1.  **The Hejlsberg Inversion:** Why you should ask AI to write programs, not just answers.
-2.  **The Tailwind Paradox:** Why AI agents prefer "ugly" utility classes over "clean" semantic CSS.
-3.  **Persona Engineering:** How to architect cognitive constraints to stop your AI from hallucinating.
-4.  **Playbooks:** Practical, copy-paste guides for "Low-Tech" web development.
-
-If you are an engineer, a knowledge architect, or just someone tired of the "black box" nature of modern AI, welcome aboard.
-
-Let’s reduce some entropy.
-
-— **pjsvis**
-
-***
-
-### Pre-Publishing Checklist (Substack Specifics)
-
-Based on general Substack best practices, here are a few settings you should tweak before hitting publish to match the "PolyVis" aesthetic:
-
-1.  **The "Welcome" Email:**
-    * *Default:* "Thanks for subscribing."
-    * *PolyVis Style:* Change this to something like: "Welcome to the structure. You have successfully lowered your input activation threshold."
-2.  **The "About" Page:**
-    * Paste the `CIP-1` definition from your `lexicon.md` here. Define yourself as "methodically exploring conceptual space."
-3.  **Visual Style:**
-    * Go to Settings -> Style.
-    * Choose "Mono" or "Clean" font settings.
-    * Use the hex code `#202124` (Your "Google Dark Gray") for accent colors if possible, to match your app's `theme.css`.
-
-### Next Step for You
-Does this draft feel aligned with your voice? We can make it more "Grumpy" (cynical about modern tech) or more "Academic" (focusing on the Scottish Enlightenment roots) depending on your preference.

package/substack/substack-playbook-2.md

@@ -1,78 +0,0 @@
-This revised draft incorporates your specific narrative points ("The Bits," "Persona Engineering Origins," "The Artifact Stack") and adopts the "Fun/Academic/Experienced" tone. It positions you not just as a coder, but as a methodologist.
-
-***
-
-### **Title:** Don't Just Search the Machine. Map It.
-**Subtitle:** Moving from "Prompt Engineering" to "Structural Information Engineering."
-
-We have access to the most powerful intelligence in human history, and all we seem to be interested in is the size of its bits.
-
-*(And yes, that is a pun. Make of it what you will.)*
-
-We are drowning in context. Every time we open a chat window, we generate a stream of brilliance, hallucinations, code snippets, and philosophical debates. But the moment the window closes, that intelligence evaporates. It becomes a "hairball"—a tangled mess of unstructured text.
-
-We have built the Oracle, but we forgot to build the Library.
-
-**Hello. I am pjsvis.**
-
-I am a builder focused on **Structural Information Engineering**. For the past few months, I have been working on a project called **PolyVis** to solve a specific problem: **How do we engineer a "Persona" that actually remembers who it is?**
-
-### The Origin: Taming the Sycophant
-
-My journey into **Persona Engineering** didn't start with a grand vision. It started with annoyance.
-
-Like many of you, I was tired of the default "Substrate" behavior of modern LLMs. You know the type: over-effusive, sycophantic, eager to please, and prone to making things up just to keep the conversation flowing. I didn't want a cheerleader; I wanted a colleague.
-
-I realized that "Prompt Engineering" was too shallow. To fix this, I needed to architect a **Persona Stack**—a set of constraints (Directives, Heuristics, Lexicons) that forced the AI to behave with "Mentational Humility."
-
-As we overcame those initial annoying tendencies, a realization hit: **Substrates are more aligned with our intentions when they have a persona that is aligned with our values and methodologies.**
-
-When I treated the AI like a Junior Engineer with a very specific "Employee Handbook," the hallucinations dropped, and the utility skyrocketed.
-
-### Agile for the AI Age
-
-As we moved into **AI-Assisted Coding**, we found that traditional Agile didn't quite fit. You can't just throw user stories at an LLM and expect clean code. You need a new set of artifacts to manage the "fuzzy" nature of probabilistic intelligence.
-
-We developed a process rooted in **Context-Driven Design**, relying on four key artifacts:
-
-1.  **The Brief:** A "Weaponised Happy Path" for a task. These tend to be ephemeral; they often don't survive contact with the reality of development, but they set the vector.
-2.  **The `_CURRENT_TASK.md`:** A safety net living in the root of the project. It tracks exactly where we are, protecting us from the "context rot" that happens when you step away for coffee (or sleep).
-3.  **The Debrief:** Formed strictly of **Accomplishments**, **Problems**, and **Lessons Learned**. This is where we admit what broke.
-4.  **The Playbook:** The destination for those lessons. We moved from a monolith of "Notes" to categorized Playbooks (e.g., `css-playbook.md`, `bun-playbook.md`). This is our crystallized wisdom.
-
-This isn't just "coding." It's a new form of project management where the "team" is synthetic, but the discipline is human.
-
-### Enter PolyVis
-
-So, what is PolyVis?
-
-It is the visualizer for this methodology. It is a **Neuro-Symbolic Graph Explorer** that takes all that "Stuff" (Directives, Heuristics, Playbooks) and turns them into "Things" (Nodes and Edges).
-
-The current industry obsession is RAG (Retrieval Augmented Generation) and Vector Databases. They work... mostly. But they give you "fuzzy vibes" based on similarity.
-
-I wanted something deterministic. I wanted to see the **Structure**. I wanted to see how a specific **Heuristic** (like *OH-104: Local Memory Block Protocol*) connects to a specific **Piece of Code**.
-
-
-
-### The "Zero Magic" Philosophy
-
-PolyVis is built on the **Principle of Effective Low-Tech Defence**.
-* **No Build Step:** It runs on standard web technologies.
-* **No React:** It uses **Alpine.js** for lightweight reactivity.
-* **Local First:** It runs on a local SQLite database (via WASM).
-
-I call this **"Zero Magic."** If I can't explain how a pixel got to the screen without referencing a black-box library, it doesn't belong in the stack.
-
-### What's Next?
-
-I am using this Substack to document the engineering, the philosophy, and the "bon mots" discovered while building PolyVis. Future posts will cover:
-
-1.  **The Hejlsberg Inversion:** Why you should ask AI to write programs to do jobs, rather than asking it to do the job itself.
-2.  **The Tailwind Paradox:** Why AI agents prefer "ugly" utility classes over "clean" semantic CSS.
-3.  **The Bestiary of Substrate Tendencies:** A catalogue of the weird behaviors we've identified in the wild.
-
-If you are an engineer, a knowledge architect, or just someone tired of the "black box" nature of modern AI, welcome aboard.
-
-Let’s reduce some entropy.
-
-— **pjsvis**

package/tasks/ui-investigation.md

@@ -1,26 +0,0 @@
-# UI Investigation & Snag List
-
-**Status**: Open
-**Owner**: User
-**Created**: 2025-12-31
-
-## Context
-A list of UI/UX issues, edge cases, and layout bugs discovered after the "Terminal Brutalist" overhaul.
-
-## Issues to Investigate
-
-### Investigation Log
-- [x] **Home Page:** Ensure "Polyvis" in header is visible. (Fixed: Added `.nav-brand` class).
-- [x] **Home Page:** Center content and remove horizontal line.
-- [x] **Home Page:** Ensure font consistency.
-- [x] **Home Page:** Remove Graph Explorer arrow and dotted line.
-- [x] **Home Page:** Fix button hover contrast (Fixed: Semantic Inversion).
-- [x] **Home Page:** Reorder buttons (Docs, Graph, About).
-- [x] **Home Page:** "Vertical Monolith" Layout (5:8 Ratio).
-- [x] **Home Page:** Uniform Gaps (Integer Scale).
-- [x] **Docs:** Fix `showSource` error.
-- [x] **All Pages:** Update CSS Playbooks.
-
-## Outstanding
-- [ ] **Mobile:** Ensure workable on touch devices.
-- [ ] **About Page:** Implement "Back" button and align visual system (currently FAFCAS Core specific).