SOP-DEV-mkdocs-publication-v1.0¶
1. Purpose¶
Define what gets published to the MkDocs documentation site, who approves content changes, how site health is monitored, and the rollback procedure when a deploy goes wrong.
What the site is: https://eco-monetize.github.io/claude/ — an internal documentation site serving vault content (agent contracts, SOPs, governance docs, knowledge base) to Rick and the agent team via GitHub Pages + MkDocs. Not customer-facing.
Audience classification: Internal only (Rick + agents). This classification matters for council review thresholds — per SOP-EXEC-council-review-v1.0 Section 2.3 (pending amendment), internal-only tooling meets the criteria for internal review rather than mandatory external LLM council review.
2. What Gets Published¶
Published (always)¶
/Claude/system/sops/— SOP library (Active and Draft SOPs)/Claude/system/agents/— agent contracts/Claude/system/org/— governance documents (missions pattern, vault structure, R&R matrix)/Claude/knowledge/— wiki subfolders (tools, platforms, best-practices, decisions)
Published (with review — see Section 3)¶
/Claude/operations/reports/— status reports, daily summaries, weekly summaries/Claude/missions/— mission workspaces (task briefs, knowledge-base.md files)
Never published¶
/Claude/sessions/— agent session directories (memory notes, handoff files, kickoff packages contain operational context not meant for indexed access)/Claude/inbox/— raw capture surface/Claude/operations/incidents/— incident files (sensitive operational state)- Any file matching the scrub patterns in SOP-DEV-daily-session-export-v1.0 Section 4
- Files in
.claude/— hooks, settings, local config
When in doubt: default to NOT publishing. Add to the published set only with explicit code.platform + CDO approval.
3. Content Approval Before Publishing¶
| Content type | Approval required |
|---|---|
| SOP changes | COO approval (per SOP-OPS-sop-change-management-v1.0) before the SOP file goes Active — publication is automatic once Active |
| Agent contract changes | chief.staff review + COO approval before publish |
| Governance docs (org, missions pattern, R&R matrix) | CEO approval before publish |
| Knowledge / wiki content | CDO or CMO approval depending on domain |
| Operations reports (daily, weekly summaries) | chief.staff approved at time of writing — no additional approval needed for publication |
| New mkdocs.yml config changes (navigation, theme, plugins) | code.platform authors + CDO approves |
What does NOT require re-approval for publication: Content already approved through its own workflow (e.g., an Active SOP, a CEO-approved governance doc). Publication is a rendering action, not a content approval action — the content was already approved when it was promoted to Active/approved status.
4. Deploy Process¶
Publication happens via GitHub Pages CI/CD triggered on push to the main branch of the vault repo. code.platform owns the deploy configuration.
Normal deploy flow:
- Content change merged to
main(through its own approval path per Section 3) - GitHub Actions builds MkDocs and deploys to
gh-pagesbranch - Site live at
https://eco-monetize.github.io/claude/within ~2 minutes - code.platform verifies site loads (HTTP 200 on root URL) after deploy
code.platform monitors the GitHub Actions build status. A failed build is treated as a SEV3 incident per Section 6.
5. Site Health Monitoring¶
| Check | Frequency | Owner |
|---|---|---|
| Site availability (HTTP 200 check) | After every deploy | code.platform |
| Build status (GitHub Actions) | After every deploy | code.platform |
| Content accuracy spot-check (sampled pages match source files) | Weekly | code.platform or documentation.engineering |
| Broken internal links | Monthly (or on MkDocs plugin report) | code.platform |
If the site goes down outside of a deploy window: code.platform files a SEV2 incident and notifies CDO. If site is down >2 hours: CDO notifies CEO.
6. Rollback Procedure¶
If a deploy produces broken navigation, missing content, or exposes content that should not be published:
- Immediate: code.platform identifies the bad commit
- Revert:
git revert {commit}onmain— triggers a new GitHub Actions build restoring the previous state - Verify: HTTP 200 check + spot-check affected pages
- Incident: code.platform files Section 6E Incident (SEV2 for content exposure, SEV3 for navigation/display issue)
- Root cause: code.platform files the root cause in the incident report and proposes a mkdocs.yml or content guard fix within 24 hours
Do NOT force-push to main to revert. Always use git revert to preserve audit trail.
Emergency content removal (content exposed that must not be published): code.platform removes the file, pushes immediately without waiting for normal review, then files the incident retroactively. Speed takes priority over process when sensitive content is live.
7. Credential Safety in Published Content¶
The MkDocs site publishes vault markdown files. Those files may have been reviewed for content but not for credential exposure in the same way the daily session export scrub operates.
Pre-publish credential check: When code.platform adds a new directory to the published set (expanding Section 2), run the credential grep patterns from credential-rotation-guide-v1.0.md against that directory before the first publish.
Ongoing: The daily session export scrub (SOP-DEV-daily-session-export-v1.0) catches credentials in session files. Published directories (system/, knowledge/, etc.) are authored content — credential exposure there is a writing discipline issue, not a scrub issue. Agents do not include credentials in authored content.
Change Log¶
| Version | Date | Change |
|---|---|---|
| v1.0 | 2026-04-21 | Initial draft — sop.manager. Authored per iOS recovery dispatch commitment (Eva, 2026-04-20). |
Owner: code.platform Executive sponsor: cdo Drafted by: sop.manager Status: Draft — pending CDO review + COO approval Version: v1.0