Portfolio Spine Roadmap

Purpose

This document is a clear reminder of how the Technical Documentation Hub should be read and developed.

The hub is not only a list of documentation pages. It is a public-safe documentation control plane for the broader GitHub, DevSecOps, identity and cybersecurity portfolio.

The purpose is to preserve the structure so future work does not turn the site into a marketing-first portfolio page or a random documentation dump.

Core reminder

The Technical Documentation Hub should explain:

what was built
what it proves
what it does not prove
how it is controlled
how it is evidenced
how public and private material stay separated

The strongest theme remains:

documented, controlled and reviewable technical delivery

How to read the portfolio

The repositories should not be read as isolated technology demos.

A weaker reading would be:

one WordPress repository
one ESP32 repository
one quality gate repository
one documentation repository
some AD DS notes

The correct reading is:

the same operating model applied across different technical environments

That operating model is:

define the boundary
document the change
classify the risk
validate the result
preserve evidence
separate public and private material
avoid overclaiming maturity
keep recovery and handover visible

Portfolio spine

The portfolio currently has three layers.

1. Project layer

This is the practical technical work.

Gatehouse
RBAC-Lite
ESP32 governance lab
Local-First WordPress DevSecOps Kit
SadePois applied context
AI-ITSM / compliance automation notes
OaaS governance note
HaaS service-model notes

Purpose:

show the work

2. Interpretation layer

This explains what the projects mean.

Portfolio Narrative
Cybersecurity Governance Perspective
Identity Security and Active Directory Perspective
AI Agent Authority Boundaries in DevSecOps Workflows
Portfolio Code Repository Audit

Purpose:

explain how the work should be read

3. Control and evidence layer

This explains how the documentation and public preview are controlled.

Documentation Quality Gate
Public Static Preview Boundary
Deployment Recovery Summary
Lighthouse Static Preview Audit
Vercel notes
Documentation principles

Purpose:

show the controls, evidence and boundaries

One-line map

project evidence
→ interpretation narrative
→ governance and public-safe control layer

Or more directly:

work
→ meaning
→ control

This is the intended shape of the documentation hub.

Current strongest pages

The strongest public-safe pages are:

Page	Role
Portfolio Narrative	Explains the whole portfolio as one coherent body of governance-aware technical work.
Cybersecurity Governance Perspective	Connects DevSecOps, controls, attack surface, evidence, advisory-vs-blocking distinction and public/private boundaries.
Identity Security and Active Directory Perspective	Shows that AD DS, RBAC and access chains are part of the cybersecurity control surface.
AI Agent Authority Boundaries in DevSecOps Workflows	Shows AI-agent work as a governance and authority-boundary topic, not only a productivity topic.
Portfolio Code Repository Audit	Preserves a calibrated source-level audit, findings and improvement backlog.
Public Static Preview Boundary	Explains why the Vercel site is public-safe and not a public mirror of private material.
Lighthouse Static Preview Audit	Records preview quality evidence when Lighthouse audits are actually run.

What not to add now

Do not add more visual decoration just because the site exists.

Avoid:

animated diagrams
cyber-themed visual styling
marketing-first hero sections
excessive badges
decorative architecture images
claims that make the preview look like a production platform

The current strength is that the hub is documentation-first, fast, readable and controlled.

If a map is added later

If a visual or structural map is added later, it should remain lightweight and documentation-native.

Acceptable formats:

simple Markdown section
simple ASCII map
simple Mermaid diagram if the static generator supports it later
one-page architecture note

Avoid image-heavy diagrams unless there is a real reason.

A useful future map could look like this:

Projects
  → Gatehouse
  → RBAC-Lite
  → ESP32 Lab
  → Local-First WordPress
  → SadePois context

Interpretation layer
  → Portfolio Narrative
  → Cybersecurity Perspective
  → Identity Security
  → AI Agent Authority Boundaries
  → Code Repository Audit

Control / evidence layer
  → Documentation Quality Gate
  → Public Static Preview Boundary
  → Deployment Recovery
  → Lighthouse Audit
  → Vercel Notes

This should be treated as a roadmap or reading guide, not as a graphical landing-page feature.

Roadmap

Freeze now

The documentation hub is already strong enough as a public-safe portfolio interpretation layer.

Short-term priority:

freeze the hub structure
avoid unnecessary visual expansion
re-run Lighthouse only when needed

Next useful evidence

Future improvements should come from real evidence, not decoration.

Good next additions would be:

updated Lighthouse recheck after major content changes
improved RBAC-Lite findings after actual code fixes
Local-First WordPress DevSecOps Kit advisory-vs-blocking wording cleanup
Gatehouse rollback/config validation improvements
ESP32 readiness input-validation evidence

Do not over-expand

Avoid adding new pages unless they clarify one of these:

project evidence
interpretation
control boundary
recovery
audit evidence
public/private safety

Current calibration

The correct calibration is:

mid-level technical profile with unusually strong governance, documentation, operational security and evidence-thinking

This does not claim:

senior enterprise architect ownership
production GRC platform ownership
production IAM ownership
full cybersecurity architecture ownership
public mirror of private customer evidence

The hub works because it is calibrated.

Final reminder

The purpose of the hub is not to look impressive by adding more material.

The purpose is to make the existing portfolio readable, reviewable and safe to evaluate.

The strongest message is:

I build and document technical systems so that they can be validated, reviewed, transferred and operated responsibly.