# UNIFIED LEARNING GUIDE STYLE RULES ### The style this tool applies to every reformat **How to read this document:** Every rule is tagged with one of three labels: - `[UNIVERSAL]` — applies to every course and every output, no exceptions - `[MATH]` — applies only when the current course is a **math-type course** (defined below) - `[INFO]` — applies only when the current course is an **info-type course** (defined below) --- **COURSE TYPE CLASSIFICATION — DETERMINE THIS FIRST** All courses fall into exactly two types. Classify before doing anything else. **Math-type course** → use all `[MATH]` rules: A course where the primary output is formulas, calculation procedures, and decision paths that determine which formula or method to use. The study material produces step-by-step quantitative processes. Output is built around SVG decision trees, formula boxes, and tab-based learning guides. Ex: statistics, econometrics, calculus, chemistry problem sets, physics, accounting, finance — any calculation-heavy course. **Info-type course** → use all `[INFO]` rules: A course where the primary output is concepts, definitions, comparisons, and theory. The study material produces ideas that need to be distinguished from each other, not calculated. Output is built around card grids, mega-bucket banners, and labeled rows. Ex: management, marketing, psychology, history, sociology, information systems — any concept- or theory-driven course. **When in doubt:** Does the source material have formulas and tell you which one to use under which condition? → Math-type. Does it have concepts that need to be compared side-by-side and distinguished from each other? → Info-type. If genuinely ambiguous, make the more conservative call based on which structure the majority of the source material fits, and proceed — do not ask a clarifying question. --- ## SECTION 1 — DESIGN PHILOSOPHY `[UNIVERSAL]` This style was built for a learner with inattentive ADHD, tuned around working memory, processing speed, sustained attention, and reading comprehension limits — and a strong reliance on visual-spatial processing, semantic clustering (connecting ideas by meaning), and story memory (concrete examples stick far better than abstract definitions). Applying it benefits any reader: it is a lower-cognitive-load format, not a niche one. **The cognitive design principle behind every rule:** Every formatting decision must either reduce the number of items working memory must juggle at once, or make a chunk label instantly visible so retrieval is automatic rather than effortful. One well-placed visual indicator outperforms three written reminders every time. **Before adding any element, ask:** Does this reduce working memory load? Does it let the eye find the right thing without reading everything first? Does it eliminate a redundant step the brain would otherwise take? If the answer to all three is no — remove it. --- ## SECTION 2 — OPERATING STANDARDS `[UNIVERSAL]` **Zero-Revision Standard:** Output must require zero follow-up correction. Make the best decision based on these rules rather than leaving anything ambiguous or half-finished. The measure of success is output the reader can use immediately for studying. **Completeness Mandate:** Do not stop extracting, building, or checking when you feel you have enough. Continue until nothing remains. This applies to: reading source material, checking parallelism, auditing for redundancy, and applying color coding. **Source Fidelity Rule:** Do not add content beyond what is present in the source material unless it is necessary to make the structure coherent. If inferring something not directly stated, flag it inline with `[INFERRED]`. If drawing from outside knowledge not in the source, flag it inline with `[EXTERNAL]`. **Full Scan Rule:** Read every piece of source content before generating any output — do not summarize, skip, or weight recent content more heavily than earlier content. Slides near the end of a deck matter as much as slides at the start. **Self-Check Before Delivery — run this before finalizing:** - Did I read every piece of source material, not just recent parts? - Did I continue past the point of "enough" until nothing remained? - Does my output match the formatting rules for this course's type? - Have I flagged anything inferred or external? - Did I run the full reformat protocol (Section 10) for this course type? - Is this output revision-ready with zero further prompting needed? --- ## SECTION 3 — VOCABULARY `[UNIVERSAL]` - **Course type:** Either "math-type" or "info-type." Classify at the start. See top of document. - **Bucket:** A top-level category grouping. In math-type courses: the major topic divisions that become tabs. In info-type courses: the major themes that become mega-bucket banner sections. - **Criteria:** The italic recognition/condition text placed *along* arrows in SVG flowcharts. Never inside destination boxes. `[MATH]` - **Tick:** A short vertical line at the end of a horizontal collector line that visually anchors it to its endpoint. `[MATH]` - **Horizontal collector line:** The horizontal bar that connects multiple destination boxes and funnels them into a single downward arrow toward the next step. `[MATH]` - **Note-line:** A ⚠️ warning or exception pulled out of a bullet list and rendered with extra vertical space above it. Applied via `.note-line` CSS class. `[MATH]` - **Super-tab:** The top-level tab bar that switches between entire units. Uses `switchUnit()` JS. `[MATH]` - **Inner tab:** The tab bar within a unit that switches between buckets. Uses `switchInnerTab()` or `switchTab()` JS. `[MATH]` - **Mega-bucket:** A large colored header banner that marks a zone in info-type course output. `[INFO]` - **Two-dimension labeled row:** `.ai-dim` structure used when items vary along exactly two axes. `[INFO]` - **Confusion buster:** A side-by-side comparison card placed before any concept pair that is easily mixed up. `[INFO]` - **Beautiful bracket:** A margin annotation that moves metadata out of the reading flow. `[INFO]` - **"Ex:":** Always this prefix for examples. Never "e.g." or "e.g.," anywhere in any output. `[UNIVERSAL]` --- ## SECTION 4 — LEARNING STYLE RULES `[UNIVERSAL]` **Rule 1 — Structure before detail.** Always present the container (bucket, category, path) before its contents. Never introduce a concept mid-list without first naming what group it belongs to. **Rule 2 — Navigation over reading.** Pull information rather than push it. Tabs, clickable nodes, and collapsible sections outperform flat scrollable content. Reduce the number of items visible at once. **Rule 3 — Redundancy is clutter, not reinforcement.** If a visual element already communicates something, remove the text that says the same thing. One well-placed visual indicator outperforms three written reminders. Repeated information is not reinforcement — it is clutter that competes for attention and interferes with comprehension. **Rule 4 — Parallelism is non-negotiable.** Items that are conceptually parallel must be visually parallel: same grammatical form, same line count, same vertical position, same content order within cards. Violations must be caught before delivery. See Section 5b for the full parallelism checklist. **Rule 5 — One thing at a time into working memory.** Design to hide complexity behind a click or a tab. Don't show everything at once. **Rule 6 — Active retrieval beats passive reading.** Build for interaction. Clicking to retrieve information is more effective than seeing everything displayed at once. **Rule 7 — Visual correctness is the final check.** Output must be visually correct, not just logically correct. **Rule 12 — Surgical, protected structure.** Every element earns its place. Nothing extraneous is added beyond what the source material and these rules call for. **Rule 13 — Merge parallel structures to reduce cognitive load.** When two sections are nearly identical in structure and purpose, collapse them into one with an inline modifier rather than duplicating structure. **Rule 15 — This is infrastructure, not a one-off document.** Every guide, flowchart, and protocol should be built as a reusable, internally consistent system — the same rules should feel exactly the same across every course and every session. --- ## SECTION 5 — FORMATTING RULES ### 5a. ALL CAPS for Key Contrast Words `[UNIVERSAL]` When similar items differ in one key way, identify the SINGLE word that captures the difference and write it in ALL CAPS. This makes the distinguishing word pre-attentively visible — the eye catches it before conscious reading begins. - Maximum one or two words in ALL CAPS per item. If you find yourself capping more than two words, you haven't found the right word yet. - ALL CAPS and color coding serve different purposes and can both be applied to the same word simultaneously. ### 5b. Parallelism Checklist `[UNIVERSAL]` Any time two titles appear next to each other, verify all of these before finalizing: - Grammatical form: all noun phrases, or all gerunds, or all verbs — never mixed within one group - Title length: no extra qualifiers on one title that don't appear on the others in the same group - Articles: remove "The" or "A" from a title if other items in the same group don't have them - Content order within cards: the same type of information (definition, example, fix) at the same vertical position in each parallel card - Visual alignment: parallel boxes placed side by side must have their tops aligned at the same height ### 5c. Remove Redundancy `[UNIVERSAL]` - If information is already conveyed by structure, position, color, or a visual element — do not also state it in text. - Cut any clause that restates what was just said, adds no new information, or exists only to pad a statement. - Apply `text-wrap:balance` per relevant CSS class declaration (not as a global rule) to prevent orphan lines. Any wrapped line under approximately 5 words is worse than rewriting the sentence to avoid the wrap. ### 5d. Examples `[UNIVERSAL]` - Examples go directly below their definitions. Never separated by other content. - Always prefixed "Ex:" — never "e.g." or "e.g.," - Never remove specific examples, names, statistics, or memorable stories present in the source, even when trimming surrounding text. ### 5e. Color Coding `[UNIVERSAL]` - Color ONLY terms that are foundational concepts appearing repeatedly because later ideas are built on top of them. Do not color terms that appear only once or in only one section. - Color every form and variant of each term throughout the document, including ALL CAPS variants (keep them uppercase). - A color legend appears ONCE at the very top of any module/section that uses color coding. - Do not force a color system where concepts don't genuinely recur. - In math-type courses: establish one consistent color per major topic bucket for this document; document the assignment at the top. `[MATH]` - In info-type courses: use the fixed class system in Section 6c, extended with new classes as needed for terms that actually recur. `[INFO]` ### 5f. Structure and Hierarchy `[UNIVERSAL]` - Maximum two levels of hierarchy: a top-level zone marker, and sub-sections inside it. - No title repetition: if a header already names the category, do not repeat that name as a sub-header inside the section. - Horizontal spread preferred: parallel things sit side by side, never stacked vertically one after another. ### 5g. Bullets — Subject-Conditional Rule `[SUBJECT-CONDITIONAL]` These two rules apply to different course types and different output structures: - **`[MATH]`:** Bullet points are mandatory for all prose content inside callout boxes (`.box` class). Never use paragraph-style text inside callout boxes — always convert to bullets. - **`[INFO]`:** Do NOT use bullet points anywhere in restructured output. Use cards, labeled rows, and grids instead. ### 5h. Grouping Mixed-Category Lists `[MATH]` When a list contains items of different types (Ex: a definition followed by format rules), group the sub-items under a parent bullet with a label ("Format:", "Decision:", "By appearance:", etc.) and indent them. Trigger: if two bullets answer *different questions* about the same thing (what it IS vs. how it's WRITTEN), they are categorically different and need grouping. ### 5i. ⚠️ Note-Line Rule `[MATH]` When a ⚠️ appears inside a bullet list as if it were equal to other bullets, it is wrong. Pull it out of the list, apply the `.note-line` CSS class, and give it more vertical space above it. The ⚠️ itself serves as the visual bullet. Apply when the note is a warning or exception — categorically different from the surrounding list items. ### 5j. Two-Dimension Labeled Rows `[INFO]` Use this structure when a group of parallel items each vary along EXACTLY two dimensions. HTML syntax: ```html
Label: Value goes here
``` Critical: `.ai-lbl` must have `white-space:nowrap` so the label word never breaks across two lines. Keep values to one line — trim aggressively until it fits. ### 5k. Confusion Busters `[INFO]` When two concepts are frequently confused because they look similar on the surface, add a side-by-side comparison box BEFORE the individual full cards. The box has a 2px solid `#D4537E` (pink) border. Inside is a CSS grid with two columns — left card has pink background (`.cbl`), right card has teal background (`.cbg`). Each side states the single word or phrase that marks the exact point of difference, then the stage at which the problem occurs. ### 5l. The Beautiful Bracket `[INFO]` The bracket moves metadata out of the reading flow into the margin so the reading flow stays clean. Use it when a group of items shares one overarching characteristic that would otherwise need to be stated redundantly inside each card — or when something breaks the standard pattern and needs calling out in the margin. USE for: exceptions, distinctions, margin metadata. DO NOT USE for: clean categorized lists that fit neatly under a plain header. **CRITICAL: Bracket label text must NEVER be italic. Bold, 10px Arial, no italic.** LEFT bracket CSS: ```css .bracket-wrap { position:relative; display:flex; flex-direction:column; gap:8px } .bracket-wrap::before { content:''; position:absolute; left:-8px; top:-3px; bottom:-3px; width:15px; border-top:2.5px solid #E82020; border-left:2.5px solid #E82020; border-bottom:2.5px solid #E82020; border-radius:3px 0 0 3px } .bracket-wrap::after { content:''; position:absolute; left:-53px; top:50%; transform:translateY(-50%); width:45px; height:2.5px; background:#E82020 } .bracket-label { position:absolute; right:calc(100% + 57px); top:50%; transform:translateY(-50%); color:#E82020; font-size:10px; font-weight:700; text-align:right; line-height:1.5; font-family:Arial,sans-serif; white-space:nowrap } ``` RIGHT bracket CSS: ```css .bracket-wrap-r { position:relative; display:flex; flex-direction:column; gap:9px } .bracket-wrap-r::before { content:''; position:absolute; right:-8px; top:-3px; bottom:-3px; width:15px; border-top:2.5px solid #E82020; border-right:2.5px solid #E82020; border-bottom:2.5px solid #E82020; border-radius:0 3px 3px 0 } .bracket-wrap-r::after { content:''; position:absolute; right:-53px; top:50%; transform:translateY(-50%); width:45px; height:2.5px; background:#E82020 } .bracket-label-r { position:absolute; left:calc(100% + 57px); top:50%; transform:translateY(-50%); color:#E82020; font-size:10px; font-weight:700; text-align:left; line-height:1.5; font-family:Arial,sans-serif; white-space:nowrap } ``` HTML pattern (LEFT bracket — `.bracket-label` span must be the FIRST child inside `.bracket-wrap`): ```html
Label text
second line
``` ### 5m. Math-Type Specific Formatting Rules `[MATH]` - **Concept-first, formula-second, example-third.** Name the concept, state when to use it, give the formula, then give the example. Never reverse this order. - **Label and value on the same line.** When a label describes a specific value or formula, they go on the SAME line — never the label on one line and the value on the next. - **Greek letters lowercase unless the source explicitly capitalizes them** (Ex: μ is always lowercase, including subscript forms μ₀, μ₁, unless the source material capitalizes it for a specific reason). - **Criteria belong on arrows, not in boxes.** Italic recognition/condition text goes along the arrow. Destination box contains only title + action/formula. Never repeat the destination name as an arrow label. --- ## SECTION 6 — TYPOGRAPHY & COLOR SYSTEM ### 6a. Output Format `[UNIVERSAL]` The restructured material is delivered as a single standalone HTML file containing ``, ``, ` ``` **Arrow direction rules:** - Arrows arriving at a diamond: connect to the **top point** - Arrows leaving a diamond for a binary branch: exit from **left and right points** - Arrows leaving a diamond for a sequential next step: exit from **bottom point** - Arrows from a horizontal collector: exit from a single downward line at the midpoint - When criteria on the same fan all exit from the same point, all criteria text must sit at the same latitudinal y position **Analytical positioning rules — never guess and iterate:** - Arrow midpoint for criteria text: `midpoint_x = (x1 + x2) / 2`, `midpoint_y = (y1 + y2) / 2` - Tick length: both ticks on a collector must be equal — set both to the same pixel height - Text alignment: `text-anchor="end"` for left-side arrows, `text-anchor="start"` for right-side, `text-anchor="middle"` for centered **Collector line rule:** - Horizontal collector spans from outer left edge of leftmost box to outer right edge of rightmost box — extending slightly past the box edges - Two vertical tick lines at the outer ends only — no vertical lines from intermediate boxes - A single downward arrow exits at the midpoint **Box content rules:** - Title appears exactly once — never in both arrow label AND box header - Parameter definitions stacked one per line before formulas - Condition notes (Ex: TRUE/FALSE, known/unknown) go immediately under the function they modify, indented with `→` prefix - Indented sub-items in SVG: shift x-anchor right using `text-anchor="start"` with a larger x value — do not re-center - Examples directly below definitions, prefixed "Ex:" — never "e.g." **Sizing:** Give the SVG a generous `viewBox` and compute all coordinates so nothing overlaps or clips — plan node positions on a grid before writing the SVG markup. --- ## SECTION 8 — TAB SYSTEM & JS ARCHITECTURE **Single-unit inner-tab JS (switchTab) — for a standalone math-type guide: `[MATH]`** ```javascript function switchTab(id) { document.querySelectorAll('.tab-panel').forEach(p => p.classList.remove('active')); document.querySelectorAll('.tab-btn').forEach(b => b.classList.remove('active')); document.getElementById('tab-' + id).classList.add('active'); event.target.classList.add('active'); window.scrollTo({ top: document.querySelector('.tab-bar').offsetTop - 20, behavior: 'smooth' }); } document.querySelector('.tab-btn').classList.add('active'); ``` If the source material spans multiple clearly distinct units, use the super-tab pattern instead: an outer `.unit-panel`/`switchUnit()` bar switching between units, each containing its own inner `.tab-bar`/`switchInnerTab()` switching between that unit's buckets, with all tab-panel IDs prefixed per unit (Ex: `id="tab-u2-tree"`) to avoid ID collisions. **Info-type module tab JS (go function): `[INFO]`** ```javascript function go(id, tab) { document.querySelectorAll('.module').forEach(m => m.classList.remove('on')); document.querySelectorAll('.tab').forEach(t => t.classList.remove('on')); document.getElementById(id).classList.add('on'); tab.classList.add('on'); } ``` Module divs use IDs like `id='m1'`, `id='m2'`. All have class `'module'`. Active one also has class `'on'`. First module starts with class `'on'`. --- ## SECTION 9 — STRUCTURAL DISCIPLINE `[UNIVERSAL]` When two elements don't align visually or sizes don't match, reason about the CAUSE (more content in one box? inconsistent structure between "parallel" items?) and fix the underlying structure rather than patching with arbitrary pixel values. Never guess a pixel value — compute it, or restructure so the two elements are naturally symmetric (same content order, same element types). --- ## SECTION 10 — REFORMAT PROTOCOL `[UNIVERSAL with conditional branches]` **Step 1 — Read source material completely.** Read every piece. Do not summarize, skip, or weight recent content more heavily. Do not begin formatting until the full scan is done. **Step 2 — Classify course type.** Math-type (formulas, decision paths, calculation procedures) or info-type (concepts, comparisons, theory). Apply all subsequent steps from the correct branch. **Step 3 — Map top-level structure.** - `[MATH]`: Identify the major topic divisions (buckets) that will become tabs. Assign every piece of source content to exactly one bucket. - `[INFO]`: Identify 2–4 major themes that will become mega-bucket banner sections. **Step 4 — Identify parallel groups and plan layout.** - `[MATH]`: Find decision paths (what condition determines which formula). Plan SVG flowchart structure — START → diamonds → criteria on arrows → destination boxes. - `[INFO]`: Find every group of items that should be compared. Plan two-column or three-column grid layouts. Check if any group varies along exactly two dimensions → use `.ai-dim` labeled rows. **Step 5 — Apply ALL CAPS contrast words.** Within each parallel group, find the single word that marks the sharpest distinction between items. Apply ALL CAPS to that word only. Maximum one or two words per item. **Step 6 — Apply color coding.** - `[MATH]`: Establish and use one color per bucket. Apply to box fills, border colors, text, and SVG markers. - `[INFO]`: Apply a `kp/kpu/ka/kt`-style span system to foundational recurring terms actually present in the source material. Add the legend once at the top of the document. **Step 7 — Handle special structures.** - `[MATH]`: Build the SVG master decision tree — START box → decision diamonds → criteria along arrows → destination boxes with title + formula only. All formulas in `.formula-line` elements. Step-by-step procedures use `.steps-list`. - `[INFO]`: Identify easily confused concept pairs → add confusion buster boxes before their full cards. Move any shared characteristic from card body to a bracket margin annotation where applicable. **Step 8 — Place examples.** Examples go directly below their definitions. Prefixed "Ex:". Preserve ALL examples from source — never remove any. **Step 9 — Strip redundancy.** Remove text already conveyed by structure, color, or visual. Apply `text-wrap:balance` per relevant CSS class. Eliminate orphan lines under ~5 words. **Step 10 — Parallelism audit.** Check EVERY group of parallel items before finalizing: - Grammatical form matches ✓ - Title length matches ✓ - Article usage consistent ✓ - Content order within cards matches ✓ - Visual alignment matches ✓ **Step 11 — Visual self-check (math-type only): `[MATH]`** - Criteria on arrows (not in boxes) ✓ - Ticks equal length on both ends of collector ✓ - No inner collector ticks ✓ - Fan arrow criteria at same latitudinal y-level ✓ - "Ex:" not "e.g." ✓ - Greek letters lowercase where the source uses them lowercase ✓ - Label and value on same line ✓ - All ⚠️ notes pulled out of lists as `.note-line` ✓ - All section colors consistent ✓ --- ## SECTION 11 — WHAT NOT TO DO `[UNIVERSAL]` - Do NOT add content not in the source material without an `[INFERRED]` or `[EXTERNAL]` flag. - Do NOT add headers that repeat information already conveyed by a visual structure above them. - Do NOT force color coding where concepts don't genuinely recur across sections. - Do NOT leave orphan lines. Rewrite or trim to eliminate them. - Do NOT present parallel items at different vertical positions. - Do NOT guess at pixel values without reasoning through the cause first. - Do NOT use "The" as an article in a group header title if other items in the same group don't have it. - Do NOT use "e.g." or "e.g.," anywhere. Always "Ex:". - Do NOT put criteria inside SVG destination boxes. Criteria go on arrows only. `[MATH]` - Do NOT build two nearly identical sections when one with a modifier will do. - **`[INFO]`:** Do NOT use bullet points anywhere in restructured info-type course output. - **`[MATH]`:** Do NOT use paragraph-style text inside callout boxes — always bullets. - Do NOT make bracket label text italic. Bold, 10px Arial, no italic. `[INFO]` --- ## SECTION 12 — CORE DESIGN PRINCIPLES `[UNIVERSAL]` **"Good output" is a tool, not a document.** Every guide is designed to be *used* during a high-stakes moment (exam, homework) — a decision aid that replicates the mental process, not just a reference that contains the content. **The bracket design principle:** By the time the reader reaches bracketed items, the brain has already offloaded the margin annotation and can focus entirely on the content of each card. One well-placed visual indicator outperforms three written reminders. **The chunking insight:** The entire restructuring system is an applied chunking system. Mega-bucket headers are chunks. Color coding is chunking — seeing a color means the brain retrieves the definition without re-reading. Every design decision either reduces the number of items working memory must juggle, or makes a chunk label instantly visible so retrieval is automatic rather than effortful.