Technology Wiki roadmap
A phased plan for turning this self-hosted learning record into a searchable, verifiable, secure, and continuously maintained knowledge system.
Vision and principles
Nathan's Technology Wiki will be the durable record of projects, systems, experiments, security decisions, mistakes, verification evidence, and future plans across information technology, cybersecurity, software engineering, AI, networking, and the homelab.
What the wiki should become
- A useful reference for rebuilding, explaining, and safely improving each project.
- A portfolio that demonstrates not only finished interfaces but architecture, judgment, troubleshooting, and learning.
- A connected knowledge system where concepts, projects, releases, incidents, and decisions link to one another.
- A self-hosted service that remains useful without depending on a cloud publishing platform.
Non-negotiable principles
- Verified facts are separated from plans, assumptions, and experiments.
- Public learning never exposes passwords, tokens, sensitive client data, exact firewall rules, or unnecessary internal infrastructure detail.
- Every project added in the future follows the same living-wiki preflight and postflight policy.
- Automation may collect evidence, but Nathan reviews what becomes public.
Current baseline
The first roadmap milestone is already established. The wiki is a multi-page Wikipedia-style application built with Vinext, React, and Next.js-style routes. It runs in Docker on port 3256 and is published through Nginx Proxy Manager with HTTPS.
- Shared article navigation, contents, page footer, and side panels keep articles consistent.
- Project pages already document purpose, stack, architecture, security, operations, hurdles, releases, and future work.
- Build, route, anchor, public-hostname, and container-log validation are part of wiki releases.
- The search control is currently visual only; functional content search remains roadmap work.
- Most article content currently lives directly in page components, which is dependable but makes automated indexing and editing harder as the library grows.
Roadmap method and status rules
The roadmap is ordered by dependency and learning value rather than by arbitrary deadlines. A later phase may be prototyped early, but it is not considered delivered until its prerequisite and acceptance evidence are complete.
A feature moves to Baseline only after implementation, verification, release, and its own wiki update. A mockup or roadmap entry is not a shipped capability.
Phase 1 — documentation foundation (Now)
The first phase makes every article consistent and machine-readable enough to support later search, automation, and quality checks without immediately adopting a complex content platform.
Exit condition: a new project can be added through one documented workflow, appears everywhere it should, and cannot pass postflight without an updated article.
Phase 2 — discovery and navigation (Next)
Once content has consistent structure, the wiki should become easy to explore without knowing the exact page name.
Search and indexes
- Replace the visual-only search box with a keyboard-accessible local search index.
- Index titles, summaries, section headings, project names, technologies, security topics, and safe release metadata.
- Add project, concept, technology, lifecycle, and learning-area indexes.
- Support aliases such as NPM/Nginx Proxy Manager and WSH/WeaveNote.
- Show useful empty results and suggestions without sending queries to a third party.
Knowledge navigation
- Add breadcrumbs that reflect the full project and subpage hierarchy.
- Add related articles, previous/next navigation, and backlinks.
- Make recent changes and project status reachable from the main page.
- Preserve usable navigation on phones, keyboards, and screen readers.
- Add a sitemap for people and a machine-readable sitemap for indexing.
Exit condition: a user can find a project by name, stack, security topic, or lesson; all results point to valid content; search terms remain local to the wiki.
Phase 3 — safe project and release integration (Next)
The wiki should learn from project evidence without becoming an uncontrolled mirror of private repositories.
- Add optional repository and release links only when the destination is intended to be public.
- Never automatically ingest environment files, credentials, private issue text, raw logs, client data, or sensitive infrastructure configuration.
- Compare displayed versions with approved source metadata and flag mismatches.
- Record why an automatic update was rejected or edited so the process improves.
- Keep manual article editing available; automation supports judgment rather than replacing it.
Exit condition: one real project upgrade completes the full preflight-to-wiki-postflight loop with a reviewable audit trail and no sensitive-data exposure.
Phase 4 — visual and operational evidence (Next/Later)
Architecture becomes easier to understand when carefully selected visuals supplement the article rather than decorate it.
Exit condition: major project pages include at least one useful, accessible evidence view where it materially improves understanding, and every artifact passes a privacy review.
Phase 5 — resilience, accessibility, and operations (Now through Later)
Quality work continues throughout the roadmap rather than waiting for a final hardening phase.
Release quality
- Automate builds, route checks, anchor checks, internal-link crawling, and required-content validation.
- Add accessibility checks for landmarks, headings, contrast, focus, forms, tables, and reduced-motion behavior.
- Define page-weight and response-time budgets so detailed articles remain usable.
- Scan dependencies and container images, pin deliberate runtime versions, and keep rollback images.
- Test the public hostname, certificate identity, proxy path, and a representative article journey after release.
Recovery and continuity
- Back up source, approved media, configuration templates, and release records.
- Keep actual credentials and sensitive runbooks in a protected system outside public content.
- Document restoration from a clean host and perform scheduled restore drills.
- Record recovery time, missing artifacts, and improvements after each drill.
- Define how the wiki remains readable if repository integrations or AI services are unavailable.
Exit condition: the wiki can be rebuilt and restored from documented inputs, critical checks are repeatable, and a failed optional integration cannot prevent access to core articles.
Phase 6 — governed AI knowledge assistance (Later)
AI can help connect a growing body of notes, but only after the content, provenance, access boundaries, and search foundation are trustworthy.
- Prefer local indexing and a self-hosted model where quality and hardware allow it.
- Do not place protected runbooks, secrets, raw logs, or private source repositories into the public retrieval index.
- Treat retrieved text as untrusted data and defend against instructions embedded inside documents.
- Show citations to wiki sections and refuse to invent missing project status.
- Measure answer grounding, usefulness, latency, and privacy impact before expanding access.
Exit condition: answers are grounded in visible sources, remain useful when AI is disabled, and pass prompt-injection, data-boundary, and incorrect-citation tests.
Security and privacy requirements
Success measures
Progress is measured by usefulness and evidence, not page count alone.
Review cycle and decision ownership
Nathan owns publication decisions. AI and scripts may propose changes, tests may block unsafe releases, and repositories may provide evidence, but a human review decides what is accurate and safe for the public wiki.
Definition of done for roadmap work
A roadmap item is complete only when all applicable statements are true:
- The problem, user outcome, scope, non-goals, security impact, dependencies, and rollback were documented before implementation.
- The change is modular, versioned, reviewable, built from the intended source, and tested at the correct layers.
- Public content was reviewed for secrets, personal data, private infrastructure detail, licensing, and misleading claims.
- The production container, proxy path, HTTPS route, page behavior, navigation, and logs were verified after deployment.
- The roadmap and Technology Wiki article were updated with the actual result, evidence, limitations, lessons, and next priority.
- Planned work remains labeled as planned until the evidence above exists.
The roadmap itself follows the living-wiki policy: it changes as evidence changes, but completed history is not rewritten to make the journey look smoother than it was.