# GitHub docs to WordPress with DocsPress > [!question] Lingering Questions > - What exact dependency or workflow condition caused the invalid-status-parameter failure? The recording stops before root cause is isolated. > - Which of the two competing workflow files DocsPress generated is actually canonical? The presenter can't tell from the UI. > - Can WordPress-specific block markup be generated at publish time from portable source Markdown, keeping GitHub rendering readable while WordPress gets richer blocks? > [!tip] Article Ideas > - "The failed demo is the useful demo" — a piece on treating unresolved live-stream failures as product feedback (pinned versions + full logs + replay) rather than something to edit out. DocsPress's own setup friction is a clean case study. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/General WordPress-to-WordPress Sync Is Unsolvable Because Environment Is Part of the Site]] — adjacent but distinct: that claim is about full site (DB+files+environment) sync being intractable; DocsPress is narrower (structured doc content with a human review gate), so the same "environment is invisible state" problem may not fully transfer > - [[3. Resources/Permanent Notes/Perm · Markdown won because it solved the format lock-in problem, not for syntax]] — directly supports the portable-source-Markdown claim (H4/Z3); don't re-atomize, just connect > [!quote] Vocabulary > - *DocsPress* — a workflow/product (docs.press) that publishes repository Markdown to WordPress and returns WordPress edits to GitHub as reviewable pull requests, aiming to give non-GitHub contributors a familiar editing surface without dropping repository review ## Bib capsule Jonathan Bossenger live-tests DocsPress, a docs-as-code bridge between GitHub and WordPress, walking through setup, a failed synchronization, and a follow-up test of agent-generated documentation. ## Author's thesis DocsPress targets a real collaboration gap — repository-first documentation excludes contributors who don't work in GitHub, while WordPress offers familiar editing — but the live run shows the tool is early: unclear prerequisite order, ambiguous authentication guidance, overlapping workflow files, and an unresolved invalid-parameter failure. The recording is useful as failure evidence and upstream feedback, not as proof the tool doesn't work or as a production endorsement. ## Key arguments (≤3) 1. **The core governance promise is repository review as the gate**: WordPress edits are meant to return as reviewable pull requests rather than silently changing repository source — this boundary needs verification for edits, conflicts, deletions, and permissions before it can be trusted. 2. **Unclear setup documentation produces a justified security hesitation**: Bossenger pauses rather than paste an access token into a GitHub file when the docs don't clearly state where secrets belong or how self-hosted vs. WordPress.com authentication differs. 3. **Generated WordPress-specific block markup breaks source portability**: docs generated in WordPress blocks don't render as readable Markdown on GitHub, arguing for a conversion layer applied at publish time rather than storing WordPress-specific markup in the source repository. ## Claim atoms ### WordPress edits return through repository review > [!quote] > "allows you to carry WordPress edits back to GitHub as a reviewable pull request" Where: ~00:05. The central governance promise of the whole workflow — needs verification across edits, conflicts, deletions, and permission edge cases before it can be trusted as a review gate. ### Secret placement blocks confident setup > [!quote] > "Not the biggest fan of putting my access token in a GitHub file." Where: ~00:25. Unclear authentication guidance produces a justified pause rather than unsafe credential handling — the good outcome of ambiguous docs, not the bad one. ### Source Markdown should remain readable > [!quote] > "Could exist in a markdown format that was readable in markdown." Where: ~01:00. WordPress-specific blocks weaken GitHub rendering; publication-time transforms can add richness without making the source opaque. ## Permanent candidates - **[P1 — new] Unclear setup documentation forces a security decision onto the user** — Bossenger's hesitation over secret placement is a genuinely distinct claim: documentation gaps don't just cause confusion, they transfer a security judgment call to whoever's following the guide. Worth its own atom. - **[P2 — skip, covered]** The portable-source-Markdown claim (H4/Z3) restates ground already held by [[3. Resources/Permanent Notes/Perm · Markdown won because it solved the format lock-in problem, not for syntax]] — connect, don't duplicate. - **[P3 — adjacent, not duplicate]** The review-boundary-preserves-governance claim (H1/Z1) is related to but distinct from [[3. Resources/Permanent Notes/General WordPress-to-WordPress Sync Is Unsolvable Because Environment Is Part of the Site]] — that note is about full-environment sync; this is about doc-content sync with an explicit human gate. Connect as adjacent, don't merge. ## Processing checklist - [ ] Reproduce the invalid-status-parameter failure with pinned action/skill versions and full redacted logs - [ ] Confirm which of the two generated workflow files is canonical - [x] Connect into relevant MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] and [[3. Resources/MOCs/DevRel MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — credential/secret-handling angle - [[3. Resources/MOCs/DevRel MOC]] — docs-as-code developer-experience angle - [[3. Resources/Permanent Notes/Perm · Markdown won because it solved the format lock-in problem, not for syntax]] — parent pattern for the portability claim - [[3. Resources/Permanent Notes/General WordPress-to-WordPress Sync Is Unsolvable Because Environment Is Part of the Site]] — adjacent sync-governance claim, different scope - [[3. Resources/MOCs/Documentation & Technical Writing MOC]] — applies-in: the docs discipline map, governance cluster; origin of the credential-placement claim - [[3. Resources/Permanent Notes/Unclear Setup Docs Force a Security Decision Onto the User]] — evidence-for: the Permanent note this source generated; Bossenger's pause over where the access token goes is its worked case - [[3. Resources/Permanent Notes/Docs Co-Located With Source Outlast a Separate Handbook Page]] — extends: DocsPress keeps documentation in the repository so it changes with the code, and returns WordPress edits as pull requests to preserve that property