Requirements Memory

This page is a working memory log for product requirements, feature desires, and non-negotiable UX direction expressed during project conversations.

Initial capture date: March 7-8, 2026.

Use this as a reference when implementing or revisiting behavior. It is not a replacement for code truth, but it should preserve product intent that would otherwise get lost in chat history.

How To Use This Log

• Record requirements that affect product behavior, IA, UI language, CMS structure, or shell interaction.
• Prefer durable intent over one-off implementation detail.
• When a requirement changes, update the relevant section instead of appending contradictory notes.
• Keep exact phrasing only when the wording itself matters to the product.
• Treat this page as project memory that survives across sessions and must be updated when durable requirements emerge in conversation.

Maintenance Policy

• requirements-memory.mdx is the canonical handbook record for durable product requirements, UX constraints, CMS needs, IA decisions, shell behavior expectations, and non-negotiables.
• When a conversation introduces or changes durable intent, update this file in the same task rather than leaving that direction only in chat history.
• If a newer decision replaces an older one, revise the existing section and add a dated note describing the replacement.
• Favor concise requirement statements over implementation detail so the file remains useful as long-term product memory.

Feature: Personal Environment Update Dialog

Product role

• The update popup is a Windows XP / Vista / Windows 7-inspired system success dialog inside the desktop environment.
• It is not just decoration. It functions as:
  • a what’s new surface
  • a narrative device for recency and biography
  • a CTA module into important areas
  • a worldbuilding object that reinforces the personal-machine fiction
• It should make recent change feel spatial, warm, and discoverable instead of looking like a blog list or banner.

Core design direction

• Use XP as the structural skeleton and Vista / 7 as the finishing layer.
• It should feel polished, authored, and production-ready.
• It must not feel like:
  • generic SaaS modal
  • browser alert
  • error joke
  • parody of Windows
  • novelty retro meme
• Visual cues requested:
  • glossy blue title bar
  • bevels, highlights, and strong framing
  • off-white or pale blue-gray interior
  • success-state iconography
  • soft shadow
  • acceptable rounded corners if they fit the XP/Vista/7 blend

Behavior and shell integration

• It should behave like a real window object, not a pasted-on modal.
• It should auto-open after the desktop settles, roughly 1.5 to 3 seconds after load.
• Only one update popup should be active at a time.
• It must support:
  • focus
  • overlap/layering
  • close
  • minimize
  • reopen
• It should be accessible through a natural shell affordance similar to XP/Vista/7. Requested placements were:
  • Start menu entry
  • natural desktop or shell icon where it feels native
  • system-tray style access was acceptable if it felt natural

Content model and CMS requirements

• The feature must be manageable through the CMS.
• CMS authoring must support either:
  • timebound posts
  • active/inactive toggles
  • or both
• A grouped release/version model was explicitly desired over a flat changelog if it produced a better implementation.
• Example desired model:
  • version 1.1
  • nested update entries under that version
  • version 1.2
  • nested update entries under that version
• Content objects should support:
  • release/version grouping
  • underlying updates/items
  • active/inactive inclusion control
  • publish/start dates
  • expiry/end dates
• The structure should make it easy to keep the component fresh without redesigning it.

Interaction and content rules

• The popup should render roughly 3 to 5 update items.
• Each update item should be concise and scannable.
• One clearly dominant CTA, with no more than two supporting actions.
• It should be readable in under 5 seconds.
• It should never cover the full desktop.
• Copy should be:
  • concise
  • warm
  • lightly system-flavored
  • human underneath the metaphor

Refinements requested after implementation

• Remove duplicate footer actions when they repeat destinations already represented in the update list.
• Specifically, Browse Recipe archive and Open wildlife desk were rejected because those destinations were already covered in the changelog itself.
• Remove the text Active Release that appeared after the release date.
• Clarify the meaning of the details control. The original Show details behavior was confusing because it mixed current release notes and archive behavior.
• The desired meaning became: a current-release-only notes toggle. The label should reflect that more clearly than Show details.

Past releases / archive behavior

• If there is an older version record such as 1.1, it should not be mixed into the primary current-release UI block.
• Older releases should be expandable separately at the bottom of the update window.
• The first drill-down control should be a centered CTA labeled like See Past Releases.
• Past releases should open a timeline view for roughly the most recent 6 months.
• Each release in that timeline should be individually expandable.
• Expanding a past release should reveal the patch notes / underlying updates for that release.
• This archive behavior should feel like the first level of drilling deeper, separate from the current update box.

Feature: Resume / Professional CV Window

Capture date

• Added from conversation on March 8, 2026.

Product role

• This page is a fully opened desktop application window inside the personal-site OS shell.
• It functions as:
  • professional CV / credibility surface
  • authored personal dossier
  • operating manual for how Ian works
  • bridge into deeper artifacts such as projects, writing, playbooks, and systems
• It must not feel like:
  • generic portfolio section
  • SaaS dashboard card layout
  • novelty retro joke
  • flat PDF resume pasted into themed chrome

Core goals

• Communicate professional credibility within roughly 10 to 20 seconds.
• Make Ian’s professional identity and working style legible at a glance.
• Preserve the illusion that this is a real local application running inside the desktop shell.
• Stay memorable and personal without losing seriousness or scanability.

Required shell behavior

• The Resume must be a real shell window, not a standalone page pattern disguised as one.
• It must include:
  • title bar
  • app icon area
  • window controls
  • menu bar
  • main content area
  • bottom status bar
• It should open from its own desktop icon.
• The Start menu’s Logged In Profile header should open this Resume / professional-profile window.
• A Start menu program entry for the professional CV is appropriate and should remain available.
• Updated March 9, 2026: the live resume content should be sourced from a structured content file rather than hardcoded arrays inside the React component so it can be edited through the site’s CMS.
• Updated March 9, 2026: the CMS-editable resume model should expose identity, executive profile, best-fit roles, competency clusters, qualifications, community work, experience, impact metrics, leadership portfolio, and footer text.

Content architecture

• Updated March 8, 2026: the Resume page should now use a three-panel structure rather than a left rail plus single main column.
• The required layout is:
  • left panel = identity + value props + competencies snapshot
  • middle panel = traditional executive resume / CV content
  • right panel = creative but useful proof-of-value modules
• The center column is the priority and should read like a real executive resume, not a stylized portfolio narrative.
• Decorative in-window copy that imitates document chrome without adding signal should be avoided on the Resume page.
• Specifically rejected on March 8, 2026:
  • fake menu text such as File / Edit / View / Favorites / Tools / Help
  • redundant in-window title strips repeating Ian Brigmann - Professional CV
  • faux file-status copy like resume.exe · verified local file · executive profile
  • abstract pseudo-system sections that are not grounded in actual resume evidence
• The left panel should contain:
  • avatar or identity block
  • name
  • one-sentence descriptor
  • quick-read summary
  • compact metadata rows
  • core value props
  • top strengths snapshot
  • one desk-note / pinned-note artifact
• The middle panel should contain:
  • professional profile summary
  • core qualifications
  • professional experience in a more traditional CV format
  • selected responsibilities
  • selected outcomes
  • functional leadership highlights
  • performance snapshot
  • leadership style
• The right panel should contain:
  • an inbox-grounded executive readout or best-fit-roles card
  • executive strengths panel
  • value creation map
  • proof-of-thought artifacts
• The right column should stay useful and evidence-based. If a module cannot be tied back to the inbox resume material, it should be removed or rewritten.
• Resume content should include concrete Club Caddie scale and performance signals when available, including client count, revenue growth, ARPU expansion, payments scale, and Looper / AI commercialization outcomes.
• Community contribution should be visible in the resume content, including:
  • Michigan State University’s 2 Day Venture participation
  • mentoring for incoming college freshmen and high school students starting their first businesses

Visual direction

• The shell should use XP-inspired window framing seriously, not as parody.
• The inside should feel like an editorial dossier rather than a normal web dashboard.
• Requested visual ingredients:
  • XP-like blue title-bar treatment
  • beveled or glossy controls
  • pale blue menu strip
  • strong window framing
  • warm paper-like interior surfaces
  • layered cards with visible borders
  • one darker contrast panel
  • one amber or yellow sticky-note moment
• Avoid:
  • purple-heavy futuristic gradients
  • black-and-white brutalism
  • flat modern monochrome SaaS styling

Tone and microcopy

• Tone should be:
  • human
  • intelligent
  • dry in small doses
  • confident without startup hype
  • slightly theatrical but restrained
• The page should contain subtle authored quirk moments, but those moments must remain trust-preserving.
• Exact or near-exact phrasing that mattered in the request:
  • the page should preserve personality without drifting into fake operating-system filler copy
  • the resume should follow the user’s inbox context rather than inventing decorative sections

Relationship to other pages

• This Resume page should feel more dossier-like, editorial, and personal than About This Site.
• About This Site should remain the more administrative / architectural system-overview page.
• Both pages must still feel like part of the same machine.

Responsive and accessibility expectations

• The page is desktop-first but must stack cleanly on narrower screens.
• The left rail should stack above the main content on smaller layouts.
• Long headlines must wrap cleanly.
• No shell chrome should clip on small screens.
• Basic accessibility requirements include:
  • semantic heading order
  • clear text contrast
  • accessible window-control labels
  • no important meaning conveyed by color alone

Feature: Recipes / Recipe Keeper Window

Capture date

• Added from conversation on March 8, 2026.

Product role

• The Recipe Keeper is not the main product and must not read like a recipe website.
• The primary product remains the desktop operating-environment metaphor.
• The recipe app is one micro-app within that larger personal machine, alongside writing, photography, archives, and other identity-bearing tools.
• It should feel like:
  • a saved kitchen archive
  • a personal utility used often
  • a container for favorite meals, annotated recipes, and repeatable rituals
• It should contribute contrast and warmth inside the desktop without taking over the whole site’s visual identity.

Structural framing

• The desktop shell is the main experience.
• The taskbar, Start menu, desktop icons, and overlapping windows remain the primary navigation system.
• Micro-apps should feel like installed personal software, not isolated web sections.
• The surviving recipe app must open as a real utility window inside the shell rather than a standalone microsite or full-page product.
• Updated March 8, 2026: the original Recipes window was retired, its shell slot was reassigned to the newer recipe app, and the canonical window title became Recipes A Taste of Home.

Shell and navigation requirements

• Favorite recipes should be reachable through desktop-native mechanisms rather than only from inside the app.
• Requested access patterns included:
  • Start menu entries
  • pinned/taskbar-style access
  • desktop shortcuts
  • command palette / search if available
  • recent/favorite surfaces inside the Recipe Keeper window
• The app should feel connected to the wider machine, not isolated from it.
• The shell relationship should signal that this is one tool in a lived-in operating environment.

Visual direction: modern lightweight shell with retro callbacks

• The site direction for this variant is:
  • modern
  • elegant
  • breathable
  • smooth and responsive
  • visually restrained
  • quietly nostalgic rather than overtly period-specific
• The correct balance was stated as:
  • modern in structure
  • retro in signals
• This means:
  • layout system = contemporary
  • motion = contemporary
  • spacing = contemporary
  • typography = contemporary
  • icons, metaphors, and interaction rituals = nostalgic callbacks
• The shell should avoid:
  • thick bevels
  • heavy gloss
  • dense chrome
  • loud XP imitation everywhere
• Preferred shell traits:
  • slimmer proportions
  • cleaner spacing
  • softer hierarchy
  • translucent or satin surfaces
  • restrained shadows
  • rounded corners with discipline
  • low-noise gradients
  • dark backdrop with selective illumination

Retro callback strategy

• Retro references should concentrate in signals, not cover every surface.
• Good callback areas include:
  • icon shapes
  • window metaphors
  • Start/taskbar patterns
  • subtle gradients
  • familiar menu structures
  • selected hover/focus states
  • file/folder/app metaphors
• The experience should feel like a designer’s reinterpretation of remembered desktop culture, not a direct OS recreation.

Recipe Keeper specific direction

• Recipes A Taste of Home should feel like:
  • a clean utility window
  • warm and personal inside
  • less fake old software
  • more beautiful small tool living on the desktop
• The app interior can use:
  • warm paper-like panels
  • clean card surfaces
  • restrained food-adjacent warmth
  • small nostalgic icons for favorites, notes, folders, and saved recipes
  • a modern sidebar with retro-inspired glyphs
  • lightweight top navigation rather than dense legacy toolbars
• The shell should stay sleek while the content area becomes intimate and domestic.

App-level behavioral expectations

• Recipes A Taste of Home should surface favorites and recent-open patterns within the window itself.
• It should preserve the idea of a personal archive rather than a faceless searchable database.
• The app should feel useful as a recurring personal tool, not like a showcase page.
• It should inherit the desktop shell’s chrome, windowing behavior, and open/close logic while maintaining a distinct interior mood.
• In-window copy should prioritize practical use over product explanation.
• Avoid large manifesto-style text blocks like explaining that the recipe keeper is “saved personal software, not a recipe site” inside the utility itself if that copy does not help the user cook, search, or open something.
• Updated March 9, 2026: recipe story and anchor fields should read like real kitchen notes, family shorthand, or personal reasons to make the dish. Avoid polished editorial phrasing that sounds generated or overly branded.
• Updated March 8, 2026: future recipe-window iterations should learn from reference patterns like Alton Brown’s recipe pages, especially the at-a-glance prep/time banner, strong hero imagery, and quick imperial/metric unit switching.
• Updated March 8, 2026: do not organize the live recipe window around editorial mood buckets like Slow Sunday, Need Ballast, or People Are Coming. That extra browsing layer should be removed rather than renamed.

Feature: Wildlife Archive Window

Product role

• Wildlife Archive is a photo-first micro-app inside the retro desktop site rather than a standalone portfolio page.
• The homepage shell can stay playful, but the Wildlife interior should calm down quickly and let the photography lead.
• The app should present wildlife work as documented encounters with field context, not as a generic portfolio grid or social feed.

Required information architecture

• The default entry view must be Featured.
• The primary navigation must be:
  • Featured
  • Encounters
  • Stories
  • Random Sighting
• The dominant viewing pattern should be a large-image detail view with short context and concise metadata, not a thumbnail wall.
• Encounters should support lightweight filtering by wildlife-observation logic such as species, habitat, season, behavior, and time of day.
• Stories should surface a smaller editorial subset with longer narrative text, but remain inside the same app rather than becoming a separate blog route.
• Random Sighting should immediately surface one archive entry without extra setup or friction.

Content and data model

• Wildlife records should support:
  • id
  • title
  • species
  • image
  • alt_text
  • location_region
  • habitat
  • season
  • time_of_day
  • behavior
  • field_note
  • story
  • long_story
  • sections
  • featured_priority
  • sort_order
  • optional camera and lens metadata
  • optional observed_at
  • optional rarity
• The CMS schema and frontmatter should match those archive fields so adding new wildlife entries stays low-friction.
• Real wildlife photo assets found in the repo should be used in the archive when available rather than leaving every entry on fallback art.

Visual and tone rules

• Wildlife copy should sound observant, calm, and personal rather than polished, theatrical, or AI-written.
• The gallery should feel archival and reflective, not commercial or algorithmic.
• Retro chrome is allowed around the window, but the photo panel, field note, and metadata need enough breathing room that the image remains the emotional center.
• When an entry has a real image, the detail view should expose accessible alt text rather than relying on decorative background-only rendering.

Responsive behavior

• Desktop can keep the richer window metaphor.
• Phone and tablet layouts should simplify into a readable stacked archive layout rather than forcing drag-window or dense desktop behaviors into a small viewport.
• Time-to-first-photo should stay short on every screen size.

Feature: About This Site / Admin Navigation Window

Product role

• This page is not a conventional about essay.
• It should act as a hybrid of:
  • system manual
  • control panel
  • machine map
  • file index
  • personal note from the builder
• Within the desktop metaphor, it should function like the administrator console for the personal machine.
• It should teach the visitor how the environment works, why it exists, and where to go next.

Core goals

• Orient the visitor.
• Act as a navigation hub.
• Deepen the world and make the machine feel internally coherent.
• Help a first-time visitor understand the site quickly.
• Reduce confusion and improve navigability.
• Reinforce that the desktop metaphor has real information architecture behind it.

Required framing

• Treat it as a System Overview / Administrator Console / About This Site hybrid.
• It should feel central, useful, and slightly authoritative without becoming corporate.
• It should feel more administrative and architectural than the Resume page.
• It must still feel like part of the same machine as the Resume page.

Placement and access

• It is currently found from Start Menu -> About This Site.
• That Start menu access path should remain valid.
• The route /intro should correspond to this system-overview experience rather than an unrelated standalone page.

Functional requirements

• The page must open as a system/admin-style desktop window with:
  • title bar
  • app icon area
  • utility/menu strip
  • main content area
  • bottom status bar
• It must explain:
  • why the site is structured as a desktop OS
  • what kinds of things live in the environment
  • how visitors should think about using it
• It must act as a navigation hub with launch points into major site areas.
• It must include a system map / architecture representation.
• It must include an authored note from the builder.
• It must include at least one environment/system status section.
• It must communicate that the site is spatial, windowed, and not primarily a linear scroll.
• It must include at least one recommended-pathways area.

Recommended content regions

• Intro / system overview hero
• Launch board for major destinations
• Architecture map or directory tree
• Recommended visitor pathways
• Builder note / owner note
• Environment status
• Status bar footer

Navigation and content expectations

• Navigation modules should feel like launchable apps, directories, or system tools.
• Suggested major destination categories included:
  • Resume / CV
  • Writing / essays / notes
  • Projects / systems / artifacts
  • Photography / recipes / personal archive
  • Contact
• The architecture map should represent how the machine is organized, not just decorate the page.
• Drive/folder framing such as C:\Professional, D:\Writing, D:\Archive, or Tools\System was explicitly considered appropriate.

Tone and visual direction

• It should feel like the nerve center of the site.
• The tone should be:
  • thoughtful
  • explanatory
  • dry and precise in small moments
  • warm underneath the system language
  • slightly ceremonial
• It must not feel like:
  • a boring sitemap
  • generic FAQ with themed chrome
  • enterprise admin backend
  • lore dump
  • pasted-in generic about page
• Compared with Resume:
  • less dossier/editorial
  • more control-panel, architecture, and machine-map energy
• Updated March 8, 2026: About This Site copy should stay plain and first-person even when the UI keeps its system language. Prefer direct explanations like why the desktop format exists and where to click first over polished portfolio phrasing that could belong to anyone.

Non-negotiables

• Must feel like part of the same machine as Resume.
• Must be more administrative and architectural than Resume.
• Must improve site navigability.
• Must include both explanation and launch functionality.
• Must make the site metaphor feel more real.
• Must not feel like a corporate backend.

Feature: Retro Game Library Window

Capture date

• Added from conversation on March 8, 2026.

Product role

• This is a desktop-OS-style Retro Game Library application window inside the broader personal site machine.
• It is not a generic portfolio section, card grid, dashboard, storefront, database table, or content feed.
• It must read as a collectible media archive where favorite games are browsed as physical artifacts rather than content cards.
• The experience should make the visitor feel like they are opening a private archive and handling real childhood media.

Core non-negotiables

• Object-first, not text-first.
• Console-specific rendering is mandatory.
• The UI must remain native to the OS shell and window system.
• Micro-imagery is mandatory in the selected-game experience.
• The implementation must prefer tactile nostalgia, specificity, and collectible energy over generic simplicity.
• Do not flatten the feature into interchangeable cards even on smaller screens unless there is no other viable option.

Shell and IA requirements

• The library must exist as a real application window inside the desktop shell.
• Top-level structure should include:
  • window chrome
  • console selector
  • main object display zone
  • selected game detail zone
  • supporting imagery zone
  • optional memory/story panel
• Launching the library should feel like opening a native part of the operating environment, not navigating to a disconnected web section.

Core UX model

• Entry flow:
  • user launches the Retro Game Library from the desktop OS
  • user switches between consoles using a selector that feels like system tabs, hardware filters, or media drawers
  • user browses games as physical objects appropriate to the selected system
• Selecting a game should open an inspection state with:
  • larger art presentation
  • supporting micro-images
  • memory notes or personal context
  • console metadata
  • optional screenshots or related media fragments
• Strongly encouraged interactions:
  • subtle parallax
  • object lift on hover
  • glossy sweep or reflection shifts
  • micro-images animating into view
  • shelf-depth illusion
• Optional premium interactions, if they stay tasteful:
  • case-open or flip metaphors
  • cartridge insertion metaphors
  • back-of-box or manual inspection
  • label zoom

Console-specific rendering requirements

• Games must be rendered according to their native media language, not through a universal card component.
• Game Boy / Game Boy Advance:
  • render as cartridge objects
  • preserve rounded silhouette, notch geometry, label proportions, shell depth, and bottom connector implication
• PlayStation 2:
  • render as black or blue-tinted PS2 case objects
  • preserve sleeve-under-plastic feel, top branding band, and stronger retail rectangular presence
• GameCube:
  • render as tighter, slightly jewel-box-like cases with cube-era eccentricity and polish
• Nintendo DS:
  • render as slimmer white or translucent cases with portable-era identity and optional dual-screen motifs in detail views

Micro-image requirements

• The selected-game experience must include many smaller curated visual fragments, not just one large hero image.
• Supported micro-image zones should include:
  • the object itself: cover art, label art, logo fragments, platform marks
  • inspection side panel: screenshot strips, detail crops, character/world fragments, disc or spine fragments where relevant
  • contextual memory zone: imagery or iconography suggesting the game’s world or personal memory
  • shelf environment: small badges, neighboring-object edges, stacked silhouettes, or other spatial supporting details
• Micro-images must enrich the selected state without competing so aggressively that the main artifact loses focus.

Asset and CMS / data-model requirements

• The implementation must be asset-ready and expandable over time.
• Each game should support fields equivalent to:
  • title
  • year
  • genre
  • console
  • coverImage
  • objectLabelImage
  • spineImage
  • logoImage
  • microImages[]
  • screenshots[]
  • memoryNote
  • studio
  • palette
  • renderMode
• Micro-image objects should support at least:
  • src
  • alt
  • type
  • priority
  • cropMode
  • placementHint
• If real assets are missing, the UI must still feel intentional through stylized fallback art, logo treatments, or world-inspired graphic fragments rather than looking unfinished.

March 8, 2026 content and metadata update

• The Retro Game Library header and console descriptive copy should read like a real person talking about kept games, not polished AI nostalgia copy.
• Redundant inspector metadata should stay hidden:
  • console field
  • series field
  • mood field
• The selected-game inspector should surface studio instead.
• The memory panel label should read Core Memories.
• Current memory-note copy is placeholder content for now and should remain obviously temporary until real first-person notes are written.
• Duplicate gallery reuse of the same image should be avoided when cover and label inputs point to the same file.
• Each title should have at least one screenshot slot populated, even if the current implementation uses stylized placeholder screenshot cards until real captures are added.
• The Game Boy family needs a visible handheld selector for:
  • Game Boy
  • Game Boy Advance
  • Game Boy SP
• Updated March 9, 2026: the handheld selector should use cropped photos of the actual handhelds instead of abstract icon shapes.
• Updated March 9, 2026: the shorthand selector text GB, GBA, and SP should stay hidden in the visible UI even if those mode ids still exist in code.
• Updated March 9, 2026: remove duplicate floating handheld art from the Retro Game Library shelf background and selected-game header; the selected-game panel should not show the Inspection state label.
• Updated March 9, 2026: Retro Game Library status lines and placeholder screenshot labels should stay literal and grounded. Do not imply a specific gameplay scene or memory if the slot is only fallback content.
• Updated March 9, 2026: the selected-game inspector should hide the visible Format field; Studio and other more specific metadata should carry the panel instead.
• Updated March 9, 2026: when real Retro Game Library cover art is readily sourceable for kept games, prefer populating the asset fields instead of leaving those titles on fallback art.

Visual direction

• The outer shell must stay consistent with the Windows-XP-adjacent site language:
  • glossy blue shell styling
  • beveled framing
  • tactile top bar
  • layered shadows
  • atmospheric dark desktop context
• Inside the window, the app may become more cinematic and object-driven, but it must not drift into generic component-library aesthetics.
• Desired material cues include:
  • semi-translucent plastic
  • glossy lamination
  • jewel-case reflections
  • printed sleeve edges
  • tasteful wear only if it improves realism
  • strong shelf anchoring and shadow logic

Accessibility and responsive rules

• Console selection and game selection must be keyboard navigable.
• Focus states must be visible.
• Text contrast must remain adequate.
• Imagery must have alt text or equivalent accessible labeling.
• Motion should never block comprehension.
• Responsive degradation should preserve object-first identity as much as possible.
• On phone-width layouts, the Retro Game Library should switch from the wide desktop shelf composition to a stacked mobile layout without breaking touch browsing or making the selected game unreadable.

Cross-Cutting Product Preferences Expressed

• Retro references should be sincere and useful before nostalgic.
• The site should avoid gimmick energy even when leaning into OS metaphors.
• The best implementations are the ones that make the machine feel more navigable, more spatial, and more personally administered.
• CMS-editable data is preferred when the feature is expected to evolve over time.
• Shell-native interaction is preferred over standalone pages when the feature is conceptually part of the operating environment.

Cross-Cutting Tone And Voice Requirements

• Added March 8, 2026.
• Ian’s personal voice should remain legible across the site. Do not let polished AI-style copy become the dominant tone.
• Prefer specific lived detail, concrete memory, real preference, and plain first-person phrasing over abstract brand language.
• Avoid stacking too many lines that sound like:
  • manifesto copy
  • generalized thought-leadership phrasing
  • self-consciously clever metaphor
  • broad claims that could belong to any polished portfolio
• The desktop / machine metaphor should support the voice, not replace it. Repeated terms like machine, environment, archive, and operating layer should be used selectively and only when they clarify something real.
• Avoid defensive meta-lines that announce the copy is not AI-generated or not templated. If the writing is personal enough, it should not need to say so.
• When choosing between “cleaner” copy and more personal copy, bias toward the more personal option as long as it stays readable.
• Pages that matter most for voice authenticity include:
  • Resume / Professional CV
  • About This Site
  • personal updates
  • writing and note surfaces

Shell Chrome And Taskbar Rules

• The Start control should sit flush against the far-left edge of the taskbar and visually fill its allotted shell space instead of appearing inset from the edge.
• Start menu anchoring should align to that same left edge so the menu feels attached to the taskbar rather than floating slightly inward.
• The Start button should use explicit shell-sized dimensions rather than browser default padding so its XP-style proportions stay stable across desktop browsers.
• The Update Center desktop icon should remain pinned to the System / Utility node neighborhood rather than drifting with persisted icon positions.
• Desktop taskbar window buttons should use explicit horizontal padding so tab text does not run into the button border on reader/page/window tabs.
• Taskbar window buttons should show meaningful app/window icons rather than generic placeholder squares.
• On mobile, if the taskbar has more than two window entries to show, the extra windows should move into an expandable selectable overflow list instead of compressing the bar indefinitely.

Desktop Layout Rules

• Our Records should be grouped with the Music icon in the desktop layout rather than living in a separate neighborhood.
• In the desktop icon field, Our Records should sit directly below Music.
• Desktop icon labels should wrap cleanly after a reasonable character width instead of truncating long names, and the wrapped label should stay center aligned under the icon.
• Desktop icon cards, label blocks, and neighborhood sections should be sized to feel comfortably readable at normal 100% desktop browser zoom rather than depending on zoomed-in browsing to feel right.

Mobile Responsiveness And Touch Shell Rules

• The desktop OS metaphor must remain intact on mobile, but interaction rules should adapt to touch instead of forcing desktop drag behavior unchanged.
• On touch devices, window movement and resizing should require an intentional gesture so normal scrolling and taps do not accidentally reposition windows.
• A press-and-hold gesture on a window title bar is the preferred entry into touch-drag mode.
• When touch-drag mode is active, windows should remain clamped to the visible viewport and should snap into a safe maximized state if they are moved toward the top edge.
• Mobile icon placement should prioritize legibility and predictable tap targets over freeform desktop density.
• Default mobile icon layout should use a structured grid or neighborhood-based stack rather than inherited desktop coordinates.
• Mobile desktop icons should use a tighter footprint than desktop so lower neighborhoods like After Hours / Outside Work are not clipped offscreen on shorter phone viewports.
• iPhone-sized mobile layouts should use phone-specific spacing and safe-area-aware shell padding rather than relying on the same compact sizing rules as tablet or narrow desktop windows.
• Touch-capable desktop or laptop hardware should not be downgraded into tablet shell mode solely because a coarse pointer is available; large desktop widths should preserve desktop icon sizing and layout.
• Mobile homepage icon placement should render from the generated phone grid, not from persisted drag positions, because phones do not support meaningful desktop-style icon rearrangement and stale saved coordinates can cause overlap.
• On phone layouts, each neighborhood’s icon rows should anchor directly under that neighborhood header rather than being centered far to the right of the label.
• On phone layouts, the vertical gap between a neighborhood header and its first row of icons should stay tight enough that the icons still read as part of that labeled group.
• On phone layouts, neighborhood containers need enough vertical budget for wrapped icon labels and second rows so After Hours icons do not visually spill into the System / Utility node group.
• Persisted icon positions may need a mobile-specific storage model so desktop placements do not produce broken layouts on small screens.
• On smaller breakpoints, windows should favor constrained maximum widths, reduced chrome density, and larger touch-target spacing rather than preserving desktop proportions literally.
• Font sizing, control sizing, and spacing should step up for touch accuracy while still preserving the retro shell character.
• Mobile window states should likely favor a single-primary-window mental model, with stacked or maximized views preferred over overlapping many small windows.
• A dedicated implementation spec for these rules lives at /handbook/admin/mobile-shell.

Maintenance Note

• Updated March 8, 2026: this file is now a required maintenance artifact, not an optional notes page.
• When future chats introduce new durable requirements, append or revise this page instead of relying on chat history.
• If a requirement here becomes obsolete, replace it with the newer decision and note the date of change.