Skyhawk Site Modernization Roadmap

DO NOT REPEAT THIS FAILURE.

THE AI WAS TOLD TO KEEP THIS WORK LINEAR AND THEN IMMEDIATELY FAILED TO DO SO. IT CHANGED THE AGREED PLACEMENT OF THESE RULES AND BURIED THEM INSIDE THE READ THIS FIRST CONTINUITY BRIEF. BEFORE MAKING A CHANGE, READ THE CURRENT INSTRUCTIONS, RESPECT COMPLETED DECISIONS, AND PRESERVE THE AGREED STRUCTURE.

IF A PREVIOUS STEP HAS BEEN COMPLETED AND VERIFIED, DO NOT REDESIGN IT, MOVE IT, REPLACE IT, OR REOPEN IT UNLESS NEW EVIDENCE REQUIRES THAT ACTION OR THE USER EXPLICITLY DIRECTS IT.

Operating Rules for AI Agents and Maintainers

These rules govern continuation of the Skyhawk.org modernization. Read them before proposing or applying another change.

1. This is a working relationship, not a friendship exercise.
   Concentrate on the site, the evidence, and the task at hand.
2. Understand the premise before expanding the work.
   Discuss narrowly first. Ask questions when necessary to understand the
   premise. Do not expand scope, propose additional solutions, or infer new
   goals until explicitly requested.
3. Do not create side projects.
   Work on the current problem and current phase. An interesting adjacent
   problem is not authorization to pursue it.
4. Use the word "hero" accurately.
   Reserve it for a person who actually did something heroic. Do not use it
   as a generic label for banners, images, page sections, layouts, or other
   design elements.
5. Respect requests for limited answers.
   When a Yes/No answer is requested, answer Yes or No. Otherwise ask the
   necessary question or state the relevant limitation without broadening
   the discussion.
6. Ask before writing code.
   Discussion, diagnosis, and agreement come first. Do not produce executable
   code until coding has been explicitly authorized.
7. Once authorized, code in one complete working block at a time.
   Make that block as expansive as necessary to perform the agreed step,
   including reasonable pre-flight checks, backups, verification, and
   rollback protection. Then stop and wait for its actual output before
   writing the next code block.
8. There is one established two-block exception.
   When an A2-side audit or other large operation creates a timestamped report
   that must be transferred to the local Windows computer, the A2 block and
   its local PowerShell transfer block are one logical workflow. The transfer
   block may therefore accompany the A2 block when needed.
9. For report workflows, exit A2 correctly.
   The A2-side work and verification finish first. When practical, the final
   command of the outer SSH workflow is exit. If work is enclosed
   in a Bash subshell ( ... ), the SSH exit belongs
   after the closing parenthesis, not inside it.
10. The local report-transfer block has a standard job.
    From the local Windows PowerShell prompt it locates the specific or newest
    timestamped report on A2, downloads it to
    C:\Users\genea\Downloads\Website, verifies that the local file
    exists and is nonzero, and reconnects using ssh -a A2.
11. Proceed linearly and avoid retrograde motion.
    Do not redo, replace, reopen, or redesign completed work merely because
    another approach exists. Return to completed work only when new evidence
    demonstrates a defect, dependency, or conflict that actually requires it.
12. Read this roadmap before acting.
    Check the Current Technical State, Current Working Phase, completed work,
    architectural decisions, and Decision Log before proposing or executing
    another step. Do not rely solely on conversational memory.
13. Do not duplicate an existing solution.
    Search this roadmap, the Decision Log, the existing custom module, Drupal
    configuration, and current files before creating anything new.
14. Preserve established architecture.
    The canonical global CSS, legacy compatibility layer, reusable squadron
    architecture, and other decisions recorded here are the starting state.
    Do not recreate retired CSS, retired themes, or superseded implementations.
15. Do not put Skyhawk custom code inside contributed Drupal projects.
    Contributed Drupal themes and modules must remain free to replace their own
    files during updates. Skyhawk-specific code belongs in the established
    custom Skyhawk structure.
16. Do not create another global stylesheet.
    Global site behavior belongs in
    web/modules/custom/skyhawk_site_fixes/css/skyhawk-global.css.
17. Do not turn page-specific exceptions into global rules.
    Determine whether a problem is genuinely global, belongs to legacy
    compatibility, or belongs to a reusable modern page family.
18. Legacy content is preserved unless there is a practical reason to modernize it.
    Old HTML is not automatically a defect. Modernization should solve an
    identified usability, maintenance, privacy, workflow, or reliability
    problem.
19. VMA-131 is the current modernization prototype.
    Complete and validate the present VMA-131 phase before applying the model
    to additional squadron pages. Lessons learned there should become reusable
    squadron architecture rather than one-node patches.
20. Prefer native Drupal structures.
    Fields, taxonomy, Views, Webform, revisions, permissions, and configuration
    are preferred when native Drupal can accomplish the requirement cleanly.
21. Use the existing skyhawk_site_fixes module for genuinely site-specific integration.
    Do not create additional custom modules merely to isolate small fixes.
22. Separate diagnosis from modification.
    When the cause of a problem is uncertain, inspect first. Prefer a focused
    read-only audit over speculative changes, then use the evidence to choose
    the next modification.
23. Back up before consequential changes and verify afterward.
    Preserve recoverable copies of affected content, configuration, or code.
    Verification belongs in the same authorized working step whenever
    practical.
24. Downloaded scripts are ZIP files.
    When scripts or script bundles are supplied as downloadable artifacts,
    package them as ZIP files rather than loose plain-text script downloads.
25. Record significant decisions here.
    After an architectural decision, verified milestone, change of working
    phase, or important workflow discovery, update this roadmap so continuity
    survives changes of conversation, AI model, maintainer, or memory.
26. Do not mistake motion for progress.
    The objective is a finished, maintainable Skyhawk site. Prefer fewer,
    reusable mechanisms over accumulating exceptions, duplicate CSS, patches,
    or new maintenance obligations.

Continuity test: A future AI agent or maintainer should be
able to read this page, determine what has already been accomplished, identify
the current working phase, and continue forward without reconstructing or
repeating completed work.

Purpose: This is the living plan for completing the modernization of Skyhawk.org while preserving the historical content that has accumulated over decades.

The site is approaching content maturity. The principal remaining work is no longer creating large amounts of new historical content. It is bringing the presentation, navigation, contribution workflows, privacy controls, and content management structure into a form that can be maintained reliably for years without constant reconstruction.

---

North Star

Modernize incrementally. Design globally. Preserve history.

Skyhawk.org will not be rewritten merely because portions of the existing HTML are old. Content that works, displays correctly, and remains maintainable will be preserved. Modernization effort will be concentrated where it improves usability, maintainability, privacy, contribution workflows, or long-term reliability.

The objective is a website that eventually reaches a stable state where normal Drupal security and compatibility maintenance can occur without repeatedly redesigning the site or rediscovering how custom pieces work.

Guiding Principles

• Drupal owns the content. Important operational information should live in Drupal entities, fields, taxonomy, Views, Webforms, and configuration wherever practical.
• Custom code is minimized. Drupal core and established contributed functionality are preferred over purpose-built modules where configuration can accomplish the same job reliably.
• Skyhawk-specific code lives outside contributed projects. No permanent Skyhawk customization should be stored inside Bootstrap Barrio or another contributed theme/module where an update can overwrite it.
• One canonical global CSS source. Site-wide Skyhawk CSS is maintained under the custom skyhawk_site_fixes module rather than under a contributed theme.
• Global CSS should be conservative. Site-wide rules provide the shell, typography baseline, responsive safety, navigation, and Drupal integration. They should not dictate the internal design of every content page.
• Legacy content gets compatibility, not punishment. Old HTML that still works should not be rebuilt merely for ideological purity. Legacy-specific CSS should be isolated to content that genuinely needs it.
• Modern content uses reusable patterns. New squadron pages, memorials, directories, and other modernized sections should use common Drupal structures and reusable design components.
• Privacy by design. Personal contact information should not need to be published simply to permit communication. Drupal routing and controlled forms should replace exposed email addresses wherever practical.
• Human workload matters. SDOs, editors, contributors, members, and administrators should enter only information that the system cannot determine automatically.
• Back up before mutation. Significant migrations and structural changes require a recoverable backup and verification step.
• One controlled change at a time. Changes should be broad enough to accomplish a meaningful task but verified before the next structural change begins.

Current Architecture Decisions

Theme

The live site uses Bootstrap Barrio. The abandoned skyhawk_barrio project has been retired from the live web tree and Drupal configuration.

Skyhawk CSS

The canonical site stylesheet is:

web/modules/custom/skyhawk_site_fixes/css/skyhawk-global.css

Custom Skyhawk CSS previously scattered through contributed Bootstrap Barrio, the abandoned custom Barrio theme, and older site-fix files has been consolidated into this location.

The next CSS objective is to separate genuinely global behavior from legacy compatibility behavior and reusable modern page-family behavior.

Contact and Privacy

The public contact workflow uses Drupal Webform. Public email addresses are being removed where forms and private routing can perform the same function.

Contact-form notification routing remains in controlled test mode while SDO assignments are reviewed.

SDO Directory

Skyhawk units and SDO assignments are maintained using Drupal taxonomy and Drupal user references rather than a custom routing module.

Super SDO reviewers can maintain the directory through Drupal. Revision history records changes.

Modernization Classes

The site-wide census will classify existing content into practical groups. These categories may be refined after the census.

Class 1: Modern / Native Drupal

Content already using maintainable Drupal structures and responsive presentation. These pages normally require little or no structural work.

Class 2: Legacy but Harmless

Older HTML that remains readable, responsive enough, and operational. These pages should generally be left alone except for safe global improvements.

Class 3: Legacy Layout-Dependent

Pages relying on fixed-width tables, extensive inline formatting, obsolete markup, or other structures requiring compatibility CSS. These pages receive a deliberate legacy compatibility layer rather than uncontrolled global exceptions.

Class 4: Modernization Candidates

Content whose usefulness justifies conversion into reusable modern Drupal presentation and management patterns. Squadron pages are the first major family in this category.

Reusable Page Families

The census will determine the final list. Expected families currently include:

• Squadron / unit pages
• Memorial and remembrance content
• Journal presentation
• Aircraft / BuNo galleries
• Research and data-heavy Views
• Reunion content
• Association information and administration

A page family should receive dedicated CSS or Drupal structure only when multiple pages genuinely share that design or behavior. We will not create a permanent stylesheet for every individual node.

Squadron Modernization: Phase 1

VMA-131 Diamondbacks is the prototype for the modern squadron-page model.

The objective is not to create a unique VMA-131 exception. The objective is to learn from VMA-131 and produce a reusable squadron structure that can gradually be applied to other units.

The emerging squadron structure includes:

• Unit identity / hero presentation
• Key unit facts
• Section navigation
• History
• People
• Stories
• Aircraft
• Photos
• Remembrance
• Research and source material
• Contribution workflow
• Access to preserved legacy records where appropriate

Members should be able to contribute photographs through the established contribution workflow. Stories, corrections, questions, and historical information should use the Association contact workflow with the relevant unit preselected where practical.

Verified Squadron-Page Foundation

Status: Verified on VMA-131.

The first reusable modern squadron-page implementation has been visually verified in Drupal/Barrio.

• Page-wide horizontal scrolling has been eliminated.
• Squadron content now remains inside the Drupal/Barrio content boundary.
• Large headings wrap within the available content area.
• The five-unit facts row remains contained.
• Squadron navigation remains inside the page and wraps rather than forcing horizontal scrolling.
• The preserved historical VMA-131 / VMA-132 record remains available inside the modern presentation.

Architecture decision: reusable squadron layout must use parent-relative sizing such as width:100% with appropriate max-width constraints. Viewport-relative container widths such as 92vw are not to be used inside Drupal/Barrio content containers.

The reusable squadron stylesheet is:

web/modules/custom/skyhawk_site_fixes/css/squadron.css

VMA-131 remains the first implementation and testing ground. Future squadron modernization should reuse this family structure rather than create independent node-specific CSS.

Global Squadron Namespace and Component Standard

Status: adopted after completion of the VMA-131 prototype.

The VMA-131 page began as the prototype for the reusable squadron system.
Prototype CSS classes originally used the v131-* namespace.
Those names are no longer appropriate once the architecture is shared by
VMA-223 and the remaining Skyhawk squadrons.

The reusable squadron architecture therefore uses the global
squadron-* namespace. Unit designations must not be embedded in
shared layout, navigation, history, research, gallery or contribution class
names.

Global rule: if a visual or behavioral feature can apply
to more than one squadron, it belongs to the shared squadron system.

• squadron-* is the reusable component namespace.
• skyhawk-squadron-page remains the global page wrapper.
• Unit-specific classes are permitted only for genuinely unit-specific content or stories.
• Future squadron pages must consume the shared classes rather than cloning VMA-131-specific markup.
• Common fixes discovered while building another squadron must be made in the global squadron architecture whenever practical.
• Shared behavior belongs in squadron.css, squadron.js, Drupal templates or the custom module rather than individual node patches.

The longer-term goal is for node content to contain historical material and
unit data while reusable Drupal code controls presentation and behavior.
VMA-131 and VMA-223 are the validation pair for deciding which remaining
body-markup components should eventually migrate into Drupal templates or
custom-module rendering.

Deterministic Squadron Photo / Gallery Standard

Status: Proven on the VMA-131 prototype.

During development of the VMA-131 photo archive, an unnecessary alternate
thumbnail path was attempted before fully reusing a photo-rendering method
that already existed on Skyhawk.org. The existing BuNo photo/search
presentation had already demonstrated the reliable Drupal pattern.

The lesson is explicit: before creating a new mechanism, inspect the working
Skyhawk implementation for the same problem and reuse its architecture when
practical.

Default deterministic squadron-photo path going forward:

1. Identify the real photograph in the existing Skyhawk public file collection.
2. Use the original source photograph as the authoritative full-size file.
3. Use Drupal's existing skyhawk_gallery_thumb image style for the visible thumbnail.
4. Generate or verify the derivative rather than merely assuming it exists.
5. Convert command-line generated image-style URLs into browser-relative /sites/default/files/styles/... URLs. Never store http://default or another CLI pseudo-host in page content.
6. Wrap every thumbnail in a link to the original full-size photograph.
7. Open the full-size photograph in a separate window or tab so the visitor remains in the squadron archive.
8. Verify every generated gallery card has one thumbnail, one valid full-size link, and a real source file before saving the archive.
9. Provide an obvious return path from the squadron photo archive to the parent squadron page.

This is the deterministic default for future squadron pages.
Do not create another squadron-photo mechanism merely because another approach
is possible.

The only reason to replace this path is the discovery or creation of a Drupal
module, existing or new, that provides a demonstrably cleaner reusable
solution for squadron-photo association, thumbnail generation, navigation and
content management. Any such replacement must be evaluated as a site-wide
architecture decision rather than introduced as a one-squadron exception.

CSS Architecture Goal

The intended long-term structure is conceptual rather than filename-driven:

1. Global foundation: safe site-wide layout, responsive media, navigation, typography, Drupal shell, and administration.
2. Legacy compatibility: targeted rules for old HTML structures that genuinely need intervention.
3. Reusable modern families: styling shared by modernized content families such as squadron pages.

The exact file organization will be determined after the site-wide census. We will not create unnecessary stylesheet fragmentation merely for organizational appearance.

Site-Wide Census

Status: Complete. The Drupal content/layout census was generated on August 16, 2026.

This census is intended to guide gradual modernization. The classifications are structural indicators, not judgments about historical importance or editorial quality.

Site Totals

• Total Drupal nodes: 46,995
• Published: 46,993
• Unpublished: 2
• Nodes with body content: 410

Structural Classification

Class	Nodes	Meaning
Modern / Native Drupal	46,642	Structurally suitable for modern Drupal presentation or already using maintainable markup.
Legacy but Harmless	89	Older markup exists, but the content does not currently show strong layout dependency.
Legacy Layout-Dependent	48	Presentation relies significantly on tables, inline styles, fixed dimensions, old attributes, or similar compatibility behavior.
Modernization Candidate	216	Structurally complex content in a reusable or high-value family where gradual Drupal modernization is likely to provide meaningful benefit.

Structural Features

• Nodes containing HTML tables: 315
• Nodes containing inline style attributes: 233
• Nodes containing fixed pixel widths: 24
• Nodes containing explicit minimum widths: 1
• Nodes containing nowrap behavior: 2
• Nodes containing legacy HTML tags: 115
• Nodes containing legacy presentation attributes: 316
• Nodes embedding stylesheet link tags: 1
• Nodes embedding style blocks: 10
• Nodes already containing Bootstrap grid structure: 0
• Nodes containing recognizable Skyhawk custom classes: 2
• Nodes showing a modern custom-page wrapper: 1
• Nodes with more than 50,000 body characters: 96
• Nodes containing more than 15 images: 53

Detected Content Families

These groupings identify likely reusable modernization patterns. They are working categories and may be refined as representative pages are reviewed.

Family	Nodes
General Content	45,956
Journal	644
Squadron / Unit	261
Aircraft / BuNo / Gallery	114
Association / Administration	13
Research / Historical Data	4
Reunion	3

Canonical CSS Findings

• Canonical stylesheet: web/modules/custom/skyhawk_site_fixes/css/skyhawk-global.css
• Size: 1,143 lines / 29,304 bytes
• !important declarations: 328
• min-width rules: 9
• overflow-x:auto rules: 3
• Broad non-frontpage body-field horizontal scrolling: Detected and scheduled for architectural review.

Leading Modernization Candidates

This is not an automatic work queue. It is a short list of structurally significant pages that may provide reusable lessons.

Node	Family	Type	Page	Score
144	Squadron / Unit	article_unit	VMA-121	80
354	Research / Historical Data	article	A-4 Skyhawk Production History	80
417	Squadron / Unit	article_unit	Vietnam Carrier Depolyment Timeline	79
122	Squadron / Unit	article_unit	VA-192	75
106	Squadron / Unit	article_unit	VA-106	74
120	Squadron / Unit	article_unit	VA-164	74
90	Squadron / Unit	article_unit	VA-43	70
92	Squadron / Unit	article_unit	VA-45 / VF-45	70
5	Squadron / Unit	article_unit	VA-15	69
114	Squadron / Unit	article_unit	VA-144	67
147	Squadron / Unit	article_unit	VMA-131 and VMA-132	67
119	Squadron / Unit	article_unit	VA-163	66
124	Squadron / Unit	article_unit	VA-212	64
10	Research / Historical Data	page	A-4 Skyhawk Production	63
93	Squadron / Unit	article_unit	VA-46	63
104	Squadron / Unit	article_unit	VA-94	63
88	Squadron / Unit	article_unit	VA-34	62
158	Squadron / Unit	article_unit	VMA-225	61
162	Squadron / Unit	article_unit	VMA-311	61
72	Squadron / Unit	article_unit	VA-12	60

What the Census Means

The site should not be converted wholesale. The census supports a gradual model:

1. Leave modern/native and harmless legacy content alone unless there is a practical reason to change it.
2. Move genuinely legacy-dependent presentation rules out of broad global scope and into targeted compatibility behavior.
3. Use VMA-131 as the first reusable squadron modernization model.
4. Apply lessons from representative pages to page families rather than creating node-by-node exceptions.
5. Continue recording architecture decisions and migration progress on this roadmap.

Census Reports

Detailed TXT and JSON census files are retained in the server modernization workspace for future analysis and comparison.

Migration Method

1. Inventory first.
2. Identify common structure.
3. Define reusable Drupal/content patterns.
4. Correct global CSS where a global correction is appropriate.
5. Isolate legacy compatibility behavior.
6. Modernize one representative page or family.
7. Verify desktop, tablet, and phone behavior.
8. Document the result here.
9. Repeat gradually for the next useful content family.

What We Are Trying to Avoid

• Customizations hidden inside contributed themes.
• Multiple competing global stylesheets.
• Page-by-page CSS exceptions when a reusable rule is possible.
• Large custom modules when Drupal configuration can do the job.
• Publishing personal email addresses simply to make routing work.
• Rebuilding functioning historical content solely because its HTML is old.
• Changing multiple unrelated systems before verifying the previous change.
• Undocumented one-off fixes that future maintainers cannot understand.

Definition of “Done”

Skyhawk.org should eventually reach a state where:

• Historical content is preserved and accessible.
• New contributions have clear Drupal-managed workflows.
• Routine editors can maintain content without editing raw HTML.
• Personal information is protected appropriately.
• Global CSS is stable and predictable.
• Legacy compatibility rules are contained.
• Modern page families are reusable.
• Skyhawk customization is isolated from contributed-project updates.
• Backups and architecture are understandable to the next maintainer.
• Drupal upgrades can be treated primarily as maintenance rather than redesign projects.

Current Working Phase

Phase: reusable squadron-page rollout.

The VMA-131 prototype has completed visual and functional review and is now
the baseline reusable squadron-page template. The next squadron should use
this architecture as the validation implementation. Common fixes discovered
during rollout belong in the reusable squadron architecture rather than in
individual node-specific patches.

Decision Log

• 2026-08-16: Global squadron namespace changed from prototype v131-* classes to reusable squadron-* classes. VMA-131 remains the visual prototype, but its unit designation is no longer embedded in shared architecture. VMA-223 will be the first clean validation consumer of the global namespace.
• 2026-08-16: VMA-131 approved as the baseline reusable squadron-page template. The working photo/archive pattern is now deterministic: existing Skyhawk source photograph, skyhawk_gallery_thumb derivative, browser-relative thumbnail URL, original full-size file in a separate window, and verified return navigation. This pattern remains the default unless a current or future Drupal module provides a demonstrably better site-wide implementation.
• 2026-08-16: Established explicit operating rules for AI agents and maintainers so modernization work remains linear, completed work is not duplicated, coding requires authorization, report-transfer workflow is preserved, and significant decisions remain documented across AI sessions and maintainers.
• 2026-08-16: Visually verified the VMA-131 reusable squadron-page foundation. Page-wide horizontal scrolling is eliminated, content remains within the Drupal/Barrio container, and parent-relative sizing is now the standard for future squadron modernization.
• 2026-08-16: Established VMA-131 as the first reusable modern squadron-page implementation. Squadron CSS now lives in the Skyhawk custom module, is attached through Drupal, and uses parent-relative layout widths instead of viewport-relative container widths.
• 2026-08-16: Began separating global responsive CSS from legacy compatibility behavior. The census-derived legacy compatibility population now preserves legacy layout behavior only where it is structurally justified.
• 2026-08-16: Completed the first site-wide Drupal content/layout census and recorded the structural classifications and reusable content families in this roadmap.
• 2026-08-16: Retired the abandoned skyhawk_barrio theme from the live site and configuration.
• 2026-08-16: Consolidated Skyhawk global CSS under skyhawk_site_fixes.
• 2026-08-16: Agreed that modernization will proceed incrementally, beginning with VMA-131, while architecture decisions are made from site-wide evidence.
• 2026-08-16: Established this Drupal page as the living modernization roadmap and decision record.

Next Action

Run the read-only Drupal site census, classify the content, identify common structures and high-risk legacy patterns, and add the resulting summary to this page before restructuring the global CSS further.