Create comprehensive proposal to migrate all content from live markusgraf.ch to the Hugo project, including text content, images, and structure. - Add proposal.md with rationale and impact analysis - Add design.md with content extraction strategy and trade-offs - Add tasks.md with 13 ordered, verifiable implementation tasks - Add content-migration spec with 5 requirements and 11 scenarios - Add image-assets spec with 5 requirements and 10 scenarios Validated with: openspec validate migrate-site-content --strict 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2.7 KiB
2.7 KiB
Design: Content Migration from markusgraf.ch
Overview
This change migrates all existing content from the live markusgraf.ch website into the Hugo-based project structure. The migration is a one-time content extraction and conversion process.
Approach
Content Extraction Strategy
Since the live site cannot be automatically fetched, we rely on the user to provide:
- HTML source code from the live site (via browser "Save As" or inspector)
- Direct access to image URLs for downloading
Content Conversion
- HTML to Markdown: Extract semantic content from HTML and convert to clean markdown
- Preserve Structure: Maintain the section hierarchy and flow from the live site
- Hugo Integration: Use Hugo's front matter and content organization patterns
Image Handling
Images follow Hugo's static asset conventions:
- Store in
static/images/(or appropriate subdirectory) - Reference in markdown as
/images/filename.ext - Organize by purpose (e.g.,
static/images/projects/,static/images/profile/)
Content Organization
content/
_index.md # Homepage with bio, intro, projects
about.md # About/CV page (if exists)
static/
images/
profile/ # Profile photos
projects/ # Project-related images
icons/ # Icons or small graphics (if any)
Trade-offs
Why Not Automate Extraction?
- WebFetch requires authentication (not available)
- Manual provision ensures accuracy and allows user to curate content
- One-time migration doesn't justify complex scraping infrastructure
Content Structure Decisions
- Single vs Multiple Pages: If live site is single-page, we keep it as
_index.md. If multi-page, we create separate content files - Project Organization: Depending on number of projects, either:
- Inline in homepage (few projects)
- Separate section with list page (many projects)
Image Optimization
- Accept images as-is from live site initially
- Future optimization (resizing, format conversion) can be separate change
- Prioritize content parity over optimization
Dependencies
- Requires user to provide HTML source and ensure images are accessible
- Depends on existing Hugo site structure from
add-minimal-hugo-sitechange
Validation Strategy
- Visual comparison: Hugo build vs live site side-by-side
- Checklist verification: Every section, image, and link accounted for
- Browser console: No 404 errors or missing resources
- Accessibility: All images have alt text
Rollback Plan
Since this is additive content migration:
- Git revert to restore placeholder content
- No breaking changes to existing Hugo structure
- Image assets can be removed from static/ directory