WSAI Change Log

Reason: OAuth2 Proxy protects custom apps; WP Google SSO may map Google identities to WP users/roles later.

Summary: Locked separate identity paths.

Implemented By: operator

Reason: AI Workspace is a framework, ChatPad is interface, memory is platform, industry workspaces are products.

Summary: Locked industry workspace product strategy.

Implemented By: operator

Reason: Community contributors, creators, customers, consultants, and agencies can become growth channels.

Summary: Locked affiliate and partner program backlog.

Implemented By: operator

Reason: Sheri persona validates multi-brand marketing team use case beyond Sam.

Summary: Locked Marketing Workspace as an industry workspace opportunity.

Implemented By: operator

Reason: Community ideas require explicit opt-in, safety review, anonymization, and human approval.

Summary: Locked opt-in community contribution model.

Implemented By: operator

Reason: Private memory, customer memory, and anonymous sessions should not be mined without explicit consent.

Summary: Locked principle: monetize insights, not people.

Implemented By: operator

Reason: The product has a tiered path from anonymous playground to enterprise memory.

Summary: Locked subscription ladder and memory-based value progression.

Implemented By: operator

Reason: Model access is commoditized; the durable value is scoped, curated, permissioned memory.

Summary: Locked platform moat around operational memory.

Implemented By: operator

Reason: The product direction shifted to ChatPad as conversational front door over memory and workspaces.

Summary: Locked ChatPad as primary interface and AI Workspace as advanced feature.

Implemented By: operator

Reason: Once wickedspooky.org/operator is behind OAuth, ChatGPT should not have anonymous direct access. Context must be provided via export, paste, Make, or controlled token-gated endpoints.

Summary: Locked principle that Operations remains private; AI context access is mediated and intentionally scoped.

Implemented By: operator

Reason: The Operations authority contains backlog, change log, database catalog, operational guides, and internal memory. It should not remain anonymously accessible after moving from WordPress pages to a raw Operator Console.

Summary: Approved OAuth2 Proxy + Google protection for wickedspooky.org/operator and internal APIs, while preserving wickedspooky.ai public site access except protected AI Workspace.

Implemented By: operator

Reason: AI Workspace, Operator Console, and future public apps may need independent performance/resource tracking before deciding whether to separate hardware.

Summary: Created WSAI_ResourceMonitor_v1 backlog item to track resource/performance data and future separation thresholds.

Implemented By: operator

Reason: Provider secrets should not be introduced until the app is behind identity-based access.

Summary: Created deployment path for OAuth2 Proxy + Google using externalized secrets and Apache reverse proxy protection.

Implemented By: operator

Reason: AI Workspace is a public-brand Content Engine application and should not be exposed inside the internal operations dashboard. Internal operations and public content apps should be separated for security and resilience.

Summary: Approved split: wickedspooky.org/operator remains internal operations; wickedspooky.ai/ai-workspace becomes protected public-brand app behind OAuth2 Proxy + Google.

Implemented By: operator

Reason: The content system should produce regular scheduled AI-augmented content across multiple brands and social streams to build audience and revenue.

Summary: Captured goal to convert operational memory, stories, and nuggets into content, opportunities, publications, and monetization streams.

Implemented By: operator

Reason: Founder may be camera-shy, but avatars and personas can publish across many brands and categories.

Summary: Captured model where Second Act Sam, Crisis Cat, WickedSpooky AI, Blue Rose Retreats, Wicked Spooky IT, and future personas can publish without founder appearing in every category.

Implemented By: operator

Reason: Legacy Airtable/Make work is not throwaway but should be demoted from creative authority to orchestration/migration source.

Summary: Airtable and Make remain valuable for workflow, scheduling, publishing, and metrics while MariaDB/AI Workspace become content authority and refinement center.

Implemented By: operator

Reason: Airtable and Make should orchestrate workflow and movement, not own idea generation and refinement.

Summary: Content Engine selects idea, operator chooses LM, generation/refinement happens in-console, approval advances to next publishing gate.

Implemented By: operator

Reason: Fast delivery produced impressive results but also scope creep; sometimes it is better to build directly than force automation and build at the same time.

Summary: Captured lesson that automation should not be built simultaneously with uncertain creative/system design unless the process is already understood.

Implemented By: operator

Reason: Automation built on assumptions can get the operator lost faster; creative work should stay visible, interactive, and reviewable.

Summary: Locked principle: do not automate creativity; capture it, organize it, augment it, then automate the movement.

Implemented By: operator

Reason: The Operator Console, Content Brain, Story Capture, Opportunity Engine, AI Workspace, and Publishing Gates now resemble a future managed platform or SaaS product.

Summary: Captured SaaS direction and need for identity, roles, permissions, and operator workflows.

Implemented By: operator

Reason: AI Workspace and future operator modules should not rely on Basic Auth if moving toward more operators or SaaS readiness.

Summary: Approved OAuth2 Proxy + Google as next security layer without adding major infrastructure.

Implemented By: operator

Reason: Creative generation and refinement should happen interactively in the AI Workspace, not hidden inside Airtable or Make automation.

Summary: Content ideas remain authority assets. Operator selects LM/provider, reviews output, updates/rejects/regenerates, and approves before downstream orchestration. Make handles scheduling, routing, publication, and metrics.

Implemented By: operator

Reason: Technical change logs preserve facts, but narrative memory preserves meaning, lessons, mistakes, and monetizable story value.

Summary: Approved operator_story_log concept to capture failures, pivots, lessons, breakthroughs, and real-world stories.

Implemented By: operator

Reason: Regular scheduled content delivery should support audience growth and monetization across multiple brands and streams.

Summary: Locked monetization goals including YouTube, blog, PDF, course, consulting, affiliate, Etsy, Printify, and brand-specific publishing.

Implemented By: operator

Reason: The existing Operator Console needs a parallel content authority to drive scheduled publishing and monetization.

Summary: Approved MariaDB-backed Content Brain with content_ideas, content_personas, content_channels, content_schedule, and content_publications.

Implemented By: operator

Reason: Legacy Airtable and Make content workflows contain valuable ideas and structure that must be curated and consolidated.

Summary: Airtable, Make, JSON2Video, and Google Sheets content systems will be inventoried and migrated into Content Authority.

Implemented By: operator

Reason: Stories and lived operational experience should become content and monetization opportunities instead of remaining in chat history.

Summary: Adopted pipeline: Story to Opportunity to Content to Backlog to Publication to Revenue.

Implemented By: operator

Reason: User may be camera-shy, but avatars and AI-augmented personas can publish consistently without requiring direct on-camera presence.

Summary: Locked avatar/persona publishing as a strategic model for regular content delivery.

Implemented By: operator

Reason: The founder does not need to appear in every category or channel, and avatars/personas can carry content streams.

Summary: Accepted persona-driven publishing across Second Act Sam, Crisis Cat, WickedSpooky AI, Blue Rose Retreats, Wicked Spooky IT, and future personas.

Implemented By: operator

Reason: Operational truth and content production have different data models and should not be forced into one backlog table.

Summary: Defined Business Brain as guides/backlog/change log/story log and Content Brain as content ideas/personas/channels/schedule/publications.

Implemented By: operator

Reason: The business objective is content, audience, monetization, and revenue; infrastructure exists to enable that engine.

Summary: Locked strategic principle that the content engine is the product and infrastructure serves content.

Implemented By: operator

Reason: Operators need to manually reprioritize work by dragging items up or down without changing the priority label.

Summary: Added sort_order to operator_backlog_items, created /operator/backlog/prioritize.php, added drag-and-drop reorder saving, and records reprioritized events plus change-log evidence.

Implemented By: operator

Reason: Backlog items need a visual distinction between lifecycle status and outcome state including completed successfully, completed with error, failed, canceled, and deprecated.

Summary: Added outcome_status to operator_backlog_items, refreshed v_operator_backlog_active, exposed outcome status in create/edit views, and added soft pastel status styling.

Implemented By: operator

Reason: tested validated

Summary: Marked backlog key WSAI_BacklogCreation_Test_001 completed.

Implemented By: operator

Backlog: Item 32

Reason: New work item created through Operator Console.

Summary: Created backlog key WSAI_BacklogCreation_Test_001 with priority low and status planned.

Implemented By: operator

Backlog: Item 32

Reason: New work item created through Operator Console.

Summary: Created backlog key WSAI_TEST_ITEM_1_20260604001613 with priority medium and status active.

Implemented By: operator

Backlog: Item 31

Reason: Operators need to maintain description and acceptance criteria directly while keeping long item pages readable.

Summary: Updated backlog item edit form to include description and acceptance criteria. Event history now uses a collapsed details/summary section by default.

Implemented By: operator

Reason: Backlog initiative entered into planning system.

Summary: Priority=medium; Status=active; Subsystem=WordPress / Navigation

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=medium; Status=deferred; Subsystem=Blue Rose Retreats / Automation

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=WordPress / MariaDB

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=Commerce / Merch

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=medium; Status=planned; Subsystem=WordPress

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=WordPress

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=active; Subsystem=DNS / Route53

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=active; Subsystem=Mail Governance

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=active; Subsystem=WordPress Security

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=Make / MariaDB / Dashboard

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=Operations / Health

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=critical; Status=active; Subsystem=MariaDB / Governance

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=critical; Status=active; Subsystem=WordPress / Operations UI

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=critical; Status=active; Subsystem=Make / Intake

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=strategic; Status=planned; Subsystem=Content Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=strategic; Status=active; Subsystem=Content Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=strategic; Status=active; Subsystem=Content Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=strategic; Status=active; Subsystem=Content Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=Content Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=deferred; Subsystem=Infrastructure

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=planned; Subsystem=Infrastructure

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=strategic; Status=active; Subsystem=Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=strategic; Status=active; Subsystem=Content Platform

Implemented By: historical_backfill

Reason: Backlog initiative entered into planning system.

Summary: Priority=high; Status=active; Subsystem=Infrastructure

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / WSAI Database Catalog. SHA256: 2c47c0e52010b8025822e8f21d95e376b5c1876a57c4ace874823d87e96293c4

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Runtime Inventory Framework. SHA256: 3e472aaff6e7f9ec6d13c907ce9ef32f1b13742103722c09345d14295a3078b9

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Repository Index. SHA256: 25f8fcb2a84e43d9ebddbe89a91f828fe020237faf163c292bb3d9ca310cef7a

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Roundcube Deployment. SHA256: e10e5e2fa7214fdf3ca660df2f243046780d26c022f774ce55d707e90977b4f6

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Domain Mail Routing. SHA256: 2e94e477c114507f490e0ef8b8d864927ad525f8bb6ea1a78599eebd685ea391

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Email Alias Manager. SHA256: a618161fe9e3d80e9be9128b9c2dd803b409c26992e392844e552b8e93d23d84

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Make Publishing Orchestration. SHA256: 9b7bd44d0ab21b3d229203b5fea998cbb0f85a8316e4905c77c03e7679b99e17

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Operational Schema Registry. SHA256: b85dc81b1cc006275e0a7e2bcd7f3c9a7d7da6443f4f6edec3d2cc94d7c2a2c0

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Bootstrap Repository Usage Guide. SHA256: 58d0ad252f23c341909195da8e3b3428439b741614a8d99a81b83dd4385d7e05

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Repository Governance Standard. SHA256: 1e460d507409789efd3a3c994842d5eb2cd86f00ce5d027b4fe1533671eddb34

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base / Operational Knowledge Base Overview. SHA256: 7651588637e901420a0fe7d210e79b73d8d3322937cc8a4efa063a96d522e4f1

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Knowledge Base. SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Operational Authority Model. SHA256: bdea8e994ffe7d6d84c6d1ef02983c025b4dec0566081bb214a1851f6d5448a8

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Documentation Governance. SHA256: 0d6c2553ab0fdfdb9e8d7b6bc7f834d45dbc2d79b85a52433b544532ac70914f

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual / Platform Overview. SHA256: 46153f9f9bf8a313fc157531b04d5fbe736cf29c9d6c40d24756e3c993f977e6

Implemented By: historical_backfill

Reason: Operational guide published and added to the operational repository.

Summary: Guide path: Operations Manual. SHA256: c37ad950fbda2e666389693b0af03e59e5e1304eb1ec41f85533527bc21fea6e

Implemented By: historical_backfill

Reason: System-level changes need durable rationale beyond chat history.

Summary: Created operator_change_log to capture application, schema, API, migration, UI, and governance changes.

Implemented By: operator

Reason: Operators need to view and safely update backlog items from the browser.

Summary: Added /operator/backlog/item.php and editable status, priority, owner, and notes fields.

Implemented By: operator

Reason: Backlog edits require traceability of what changed, when, and why.

Summary: Created operator_backlog_events and seeded imported events for existing backlog items.

Implemented By: operator

Reason: Backlog records existed in multiple systems and needed one operational authority.

Summary: Created operator_backlog_items and consolidated product and program backlog sources into one canonical table/view.

Implemented By: operator

Reason: Operational guides needed API access for browser views, Make, AI context, and future MCP consumption.

Summary: Created operator_guides and guide APIs; added /operator/guides/ browser.

Implemented By: operator

Reason: WordPress was creating friction for dynamic operational applications, scripts, tables, and API-driven context.

Summary: Created /operator/ as the working operational console while keeping WordPress as archive/publishing authority.

Implemented By: operator

Reason: Historical changes should be captured without relying on conversation memory.

Summary: Created operator_change_log_drafts, seeded guide/backlog drafts, built draft review UI, and bulk promotion workflow.

Implemented By: historical_reconstruction

Reason: Backlog should be maintained from Operator Console.

Summary: Added controlled editing of status, priority, owner, and notes with event capture; fixed DB grants to permit writes.

Implemented By: historical_reconstruction

Reason: Operators need item-level view and audit history.

Summary: Added /operator/backlog/item.php, seeded imported events, and changed list links to human detail pages.

Implemented By: historical_reconstruction

Reason: End state requires one backlog system, no legacy split.

Summary: Created operator_backlog_items and operator_backlog_events, loaded product and program backlog sources, and created v_operator_backlog_active.

Implemented By: historical_reconstruction

Reason: Backlog needed a dedicated application backed by MariaDB.

Summary: Built /operator/backlog/ and backlog APIs, initially against product backlog view, then moved to consolidated view.

Implemented By: historical_reconstruction

Reason: Humans needed normal browser access to migrated guides.

Summary: Built /operator/guides/ with search, guide list, detail rendering, metadata, and JSON links.

Implemented By: historical_reconstruction

Reason: AI/Make/MCP need machine-readable operational context.

Summary: Added guide APIs including guide index, guide detail, guide search, and ai-context endpoints.

Implemented By: historical_reconstruction

Reason: WordPress stripped scripts and created friction for dynamic operational tooling.

Summary: Pivoted Operator Console to raw Apache/PHP under /operator/ for speed, less restriction, and future UI/API expansion.

Implemented By: historical_reconstruction

Reason: Databases and schema needed documentation in the Operations Guide.

Summary: Generated and published WSAI Database Catalog, linked from Operations Manual first page, then pivoted toward dynamic Operator app.

Implemented By: historical_reconstruction

Reason: Real operational/property issues should become future content and work items.

Summary: Created WSAI_RealWorldProblemResolutionLibrary_v1 page/work item for toilet flapper diagnosis using food dye test.

Implemented By: historical_reconstruction

Reason: Operator asked to avoid PowerShell wrappers when already connected to server.

Summary: Locked command responses: WEB/MAIL targets use direct server-console bash; PowerShell only for workstation tasks.

Implemented By: historical_reconstruction

Reason: Unsafe or irrelevant files should be blocked before download.

Summary: Locked Make Watch Files → Get File filter with filename ends with .sh; .json/.sha256 blocked before download.

Implemented By: historical_reconstruction

Reason: New domains needed default mailbox routing rules.

Summary: Locked sheri@artofsheri.com and sheri@dancelifeclothing.com to deliver to Sheri mailbox identity by default.

Implemented By: historical_reconstruction

Reason: New mail domains need repeatable DKIM onboarding.

Summary: Locked selector wsai2026 and validated DKIM public key as the current standard for new mail domains unless key rotation authority replaces it.

Implemented By: historical_reconstruction

Reason: DKIM public keys exceed DNS string length limits.

Summary: Locked multi-segment quoted DKIM TXT records for Route53/DNS automation and mail-domain onboarding.

Implemented By: historical_reconstruction

Reason: Workspace path confusion caused artifact placement risk.

Summary: Locked canonical OneDrive_new WSAI root as authoritative default and prohibited creating missing root automatically.

Implemented By: historical_reconstruction

Reason: Long-term operations should move away from direct manual server work.

Summary: Locked Make-first direction for AI calls, server-side scripts, discovery, capture, and documentation workflows.

Implemented By: historical_reconstruction

Reason: Manual file edits increase drift and error risk.

Summary: Locked script/package-based server updates instead of telling operator to edit files manually in nano.

Implemented By: historical_reconstruction

Reason: Deployment debugging produced reusable public content.

Summary: Captured package naming, StrictMode failures, logs, FailureSnapshot, intake lifecycle, and Make/SSH lessons as public content angles.

Implemented By: historical_reconstruction

Reason: Merch was identified as more than background branding.

Summary: Updated strategy to treat merch as likely high-revenue stream with Etsy/Printify and seasonal opportunity planning.

Implemented By: historical_reconstruction

Reason: Infrastructure build should support content, monetization, and public trust.

Summary: Locked infrastructure as content source and public build-in-public narrative rather than purely internal engineering.

Implemented By: historical_reconstruction

Reason: Make Parse JSON requires clean stdout.

Summary: Locked stdout as machine-readable JSON only and stderr for human logs and banners across server-side runners.

Implemented By: historical_reconstruction

Reason: Duplicate download artifacts caused package ambiguity.

Summary: Locked duplicate browser suffix files like (1).zip as intake contamination, not normal package versions.

Implemented By: historical_reconstruction

Reason: Deployments needed immutable evidence and analytics-ready history.

Summary: Locked per-run logs, package history logs, and global DeploymentRegistry.csv with FailureSnapshot.json on failure.

Implemented By: historical_reconstruction

Reason: Operational reality needed documented runtime inventory.

Summary: Published Runtime Inventory Framework and related inventory categories including apache, dns, filesystem, MariaDB, scripts, scheduler, server, validation, and WordPress multisite.

Implemented By: historical_reconstruction

Reason: Subsystem documentation needed an indexed private repository.

Summary: Published Operational Knowledge Base overview, repository governance, bootstrap guide, and subsystem pages.

Implemented By: historical_reconstruction

Reason: Operational authority needed private documentation.

Summary: Published Platform Overview, Documentation Governance, and Operational Authority Model under Operations Manual.

Implemented By: historical_reconstruction

Reason: ICMP was intentionally blocked and should not trigger false outage response.

Summary: Locked service-port validation over ping for mail.wickedspooky.org; IMAPS 993 and SMTP 587 are authoritative checks.

Implemented By: historical_reconstruction

Reason: Artifacts needed a single workstation-side authority.

Summary: Established OneDrive WSAI workspace structure for artifacts, bootstrap packages, scripts, docs, backups, snapshots, and logs.

Implemented By: historical_reconstruction

Reason: Operations needed consistent workstation-to-server execution.

Summary: Locked PowerShell as operator console, SSH as transport, and servers as execution targets.

Implemented By: historical_reconstruction

Reason: Webmail needed production proof.

Summary: Validated HTTPS Roundcube login, IMAPS 993, SMTP submission 587, send and receive through mail.wickedspooky.org.

Implemented By: historical_reconstruction

Reason: Webmail should not be installed on the mail host.

Summary: Locked Roundcube on web behind Apache as webmail.wickedspooky.org; mail host remains Postfix/Dovecot only.

Implemented By: historical_reconstruction

Reason: Aliases can exist before public MX routing is valid.

Summary: Locked domain routing/DNS state separately from alias state, including MX, DNS validation, mail routing status, and last verification timestamp.

Implemented By: historical_reconstruction

Reason: Shared aliases needed visibility by authorized mailbox, not one global mailbox.

Summary: Locked mailbox identities as domain-independent and aliases as domain-specific governed objects with alias-to-mailbox authorization mapping.

Implemented By: historical_reconstruction

Reason: Direct Make-to-MariaDB exposure was not preferred.

Summary: Locked Make → SSH → server-side local MariaDB execution as the standard DB automation pattern.

Implemented By: historical_reconstruction

Reason: Publishing needed a database-enforced readiness check.

Summary: Created and validated v_publishing_items_ready_to_publish requiring taxonomy, media, and WordPress draft readiness.

Implemented By: historical_reconstruction

Reason: The publishing chain needed proof before hardening.

Summary: Validated queued through published lifecycle with image, media manager, taxonomy mapper, and publisher validation gates.

Implemented By: historical_reconstruction

Reason: Media generation needs OpenAI, Replicate, and manual asset flexibility.

Summary: Allowed OpenAI for tests, Replicate for LoRA/persona work, and OneDrive/Dropbox/manual assets as sources.

Implemented By: historical_reconstruction

Reason: Published posts require approved branded imagery.

Summary: Locked featured image governance and media_ready step before taxonomy_mapped and published.

Implemented By: historical_reconstruction

Reason: Unmapped categories/tags could create inconsistent public content.

Summary: Added taxonomy_mapped lifecycle state and taxonomy mapping status before final publish.

Implemented By: historical_reconstruction

Reason: Publishing needed governance before public release.

Summary: Locked lifecycle queued → ai_draft → human_review → approved → wordpress_draft_created → media_ready → taxonomy_mapped → published.

Implemented By: historical_reconstruction

Reason: Admin login needed to work reliably behind HTTPS/proxy routing.

Summary: Corrected cookie/proxy behavior including forwarded protocol handling for WordPress login stability.

Implemented By: historical_reconstruction

Reason: Brand sites required a stable publishing foundation.

Summary: Validated WordPress multisite setup, GeneratePress theme, core pages, menus, permalinks, and production brand site structure.

Implemented By: historical_reconstruction

Reason: Curated artifact packages are more reliable than raw conversation exports.

Summary: Preferred curated operational artifact packages for milestone ingestion into Make, MariaDB, RAG, and archives.

Implemented By: historical_reconstruction

Reason: Major pivots need durable package generation instead of relying on raw chat history.

Summary: Locked trigger phrases including Lock the artifacts and Bootstrap Pivot and Artifact Update Recommended for artifact packages and bootstrap updates.

Implemented By: historical_reconstruction