WRDP

19 min read

🧭 Captain’s Log

Historical record — 2026-07-30

Raw append-only question and decision chronology, preserved as observed. Current truth: Program Masterplan.

Conclusion: 2026-07-30 private service

Append chronology below. The orchestrator is the sole writer. Preserve exact answers, rejected alternatives, evidence, and downstream implications.

2026-07-30T18:30:00Z — Session S-001

Subject: Operate QuizWizz privately while allowing public site use, without publishing a plugin artifact.
Hypothesis: A private, operator-controlled hosted service is distinct from plugin distribution, but it requires a separate public-service operating model.
Confidence: 0.60
Mode: smoke

2026-07-30T18:30:00Z — Finding F-001

Statement: The WordPress application is loopback-bound, while Nginx terminates TLS for wrdp.loca.zone and proxies requests to 127.0.0.1:51080; a metadata-only request to the public homepage returned 200.
Status: confirmed
Evidence grade: E3
Source: docker-compose.yml:26-40; /etc/nginx/sites-enabled/wrdp.loca.zone:1-24; curl -I https://wrdp.loca.zone/.
Implication: The system is publicly reachable as a hosted site even though Compose itself is loopback-only.

2026-07-30T18:30:00Z — Finding F-002

Statement: Public metadata-only access to https://wrdp.loca.zone/wp-content/debug.log returned 200 with Content-Length: 15465; WordPress debug logging is enabled.
Status: confirmed
Evidence grade: E3
Source: docker-compose.yml:33-37; curl -I https://wrdp.loca.zone/wp-content/debug.log.
Implication: This is an immediate public-service NO-GO until the log is made inaccessible and a subsequent metadata-only check proves denial. No log contents were retrieved.

2026-07-30T18:30:00Z — Finding F-003

Statement: Anonymous craft, generation, PDF-preview, and gameplay routes are intentional public capabilities with payload guards and database-backed limits; bearer-token ephemeral links can be used by any recipient until expiry.
Status: confirmed
Evidence grade: E2
Source: includes/Rest/{GenerateController,QuizController}.php; includes/{RateLimiter,QuizAccess,ExposureSettings}.php.
Implication: The operator must choose the allowed guest outcomes, content/key policy, and token-retention policy; these are product/operations decisions rather than hidden defaults.

2026-07-30T18:30:00Z — Finding F-004

Statement: Existing release-ineligibility documentation governs a distributable plugin artifact, not readiness to operate a public hosted service. Full backups, restore drills, monitoring, update governance, and visitor-visible privacy/terms evidence are unproven in the current bench materials.
Status: confirmed
Evidence grade: E2
Source: q5vault/audits/qwizz/2026-07-30-release-readiness.md; docker-compose.yml; includes/Admin/{Privacy,SettingsBackup}.php; SOURCE-PROVENANCE.md.
Implication: Do not equate “not a plugin release” with “safe to serve publicly.”

2026-07-30T18:30:00Z — Assumption/Risk/Conflict R-001

Statement: “Private project” is assumed to mean one operator-controlled hosted service and no distribution of a plugin archive, not secrecy of all visible public service behavior.
Owner: user.
Verification: Settle Q-001.
Revisit trigger: User intends code/artifact distribution, invite-only access, or a different confidentiality boundary.
Impact: Defines whether public-service controls are required and which later questions apply.

2026-07-30T18:30:00Z — Question Q-001

Decision: Choose the primary operating boundary.
Why it matters: The current public debug-log exposure and absent operating controls are blocker risks only if WRDP is intended to be a public hosted service.
Recommendation: Treat it as a production-like hosted service, but freeze expansion of public exposure until baseline gates are closed.
Options presented: Production-like hosted service; verification lab; limited invite-only pilot.

2026-07-30T18:30:00Z — Decision D-002

Choice: Build a private ZIP for installation on one separately operated WordPress site; its frontend will be public, but the plugin will not be published in a plugin repository.
Owner: user.
Exact answer: “this very version wrdp.loca.zone is the breeding ground and complete private but bublic means it will be zipped when done and that zip will be osed on a different single wordpress page not in wordpress plugins repository (so in a way private) but the frontend will be public on one single project online”
Rationale: The desired product is a private, operator-controlled deployment to one public site, not public distribution of a plugin artifact.

Rejected

  • Treating WRDP itself as the target production service.
  • Treating “unpublished” as a reason to ignore public-service security and operations.

Implied consequences

  • Separate target-site deployment readiness from canonical plugin-release eligibility.
  • Do not claim the absent locked canonical pipeline can produce the requested target-site ZIP.
  • Settle public visitor capability before designing target exposure and abuse controls.

Traceability

  • Requirement/AC: One privately supplied installable artifact for a separately operated WordPress site with a public frontend.
  • Implementation constraint: No marketplace/repository publication and no release-ready claim.
  • Verification: Target-site installation and public-service readiness checks only after alignment and explicit execution authorization.

2026-07-30T18:30:00Z — Question Q-002

Decision: Choose the initial public visitor capability.
Why it matters: Public craft/PDF generation is a material anonymous workload and disclosure surface beyond published-quiz play.
Recommendation: Published-quiz play only until public-service baseline gates are proven.
Options presented: Published play only; public craft and PDF; full self-service.

2026-07-30T18:30:00Z — Decision D-003

Choice: Full self-service.
Owner: user.
Exact answer: “Full self-service”
Rationale: The public frontend on the single target site should expose the widest QuizWizz visitor capability.

Rejected

  • Published quizzes only.
  • Play plus craft/PDF without the wider self-service controls.

Implied consequences

  • The target exposure matrix, selected answer-key/presentation controls, uploads, fine-tuning, bearer-link retention, rate limits, and capacity need an explicit service policy.
  • The public-service baseline must be stronger than for published-quiz play only.

Traceability

  • Requirement/AC: Public target site supports full self-service within explicitly settled controls.
  • Implementation constraint: No plugin repository/marketplace publication.
  • Verification: Controlled end-to-end guest journeys and abuse/control checks after alignment and explicit execution authorization.

2026-07-30T18:30:00Z — Question Q-003

Decision: Choose the external-data policy for AI and remotely fetched banners.
Why it matters: These optional features change the visitor data-flow, provider-risk, notice, and support boundary.
Recommendation: Keep both off initially and use local/site-owned assets.
Options presented: Both off; remote banners only; AI with approved policy; both enabled with approved policy.

2026-07-30T18:30:00Z — Decision D-004

Choice: Both optional external-data features may be enabled with approved policies.
Owner: user.
Exact answer: “Both with approved policy”
Rationale: The target public service may use AI and remotely fetched banners, provided their full provider/data/retention/disclosure/abuse/support policy is approved.

Rejected

  • Both features off initially.
  • Remote banners only.
  • AI only.

Implied consequences

  • Feature enablement remains blocked until the named policy and public disclosure are defined and verified on the target site.
  • The policy must cover AI prompt/actor data, provider terms and retention, banner-host network disclosure, budget/abuse controls, and incident/support handling.

Traceability

  • Requirement/AC: Both optional feature paths are permitted only under the approved-policy gate.
  • Implementation constraint: No vendor/data-flow claim without source- and configuration-specific evidence.
  • Verification: Target configuration, visitor notice, provider-policy review, and controlled end-to-end behavior after alignment and explicit execution authorization.

2026-07-30T18:30:00Z — Question Q-004

Decision: Choose the target service reliability commitment.
Why it matters: The desired full-self-service public service needs an intentionally chosen recovery, patch, monitoring, and support posture.
Recommendation: Resilient private service with a named operator, encrypted off-host backups, restore drills, monitoring, scheduled patching, and no formal SLA.
Options presented: Best effort; resilient private service; high availability.

2026-07-30T18:30:00Z — Decision D-005

Choice: Best effort.
Owner: user.
Exact answer: “Best effort”
Rationale: The private public service will not make a formal availability or support SLA.

Rejected

  • Resilient private service.
  • High availability.

Implied consequences

  • Public wording must not promise uptime, response times, backup guarantees, or managed support that are not actually operated.
  • Critical safety gates remain non-negotiable: no public debug logs, secure ingress, recoverable changes, privacy truthfulness, and a named way to take the service down safely.

Traceability

  • Requirement/AC: Public communication accurately describes best-effort operation with no formal SLA.
  • Implementation constraint: Do not use the lower commitment to bypass security or data-protection controls.
  • Verification: Verify the minimum safety baseline rather than high-availability properties.

2026-07-30T18:30:00Z — Question Q-005

Decision: Choose anonymous versus account-required full self-service.
Why it matters: This sets the public abuse, privacy, persistence, registration, and user-journey boundary.
Recommendation: Anonymous self-service with optional accounts.
Options presented: Anonymous with optional accounts; sign-in required; anonymous play but sign-in for creation/PDF.

2026-07-30T18:30:00Z — Decision D-006

Choice: Anonymous full self-service with optional WordPress accounts.
Owner: user.
Exact answer: “Anonymous plus optional accounts”
Rationale: Keep the guest journey frictionless while offering logged-in users a saved library and statistics.

Rejected

  • Sign-in required for all functionality.
  • Anonymous play only, with sign-in required for creation/PDF.

Implied consequences

  • Guests require short-lived pseudonymous rate-limit/attempt records and clear disclosure.
  • Account lifecycle, security, and erasure handling remain part of the hosted-service boundary.

Traceability

  • Requirement/AC: Guest self-service works without registration; accounts are optional enhancements.
  • Implementation constraint: Do not make account/data-retention claims beyond target-site configuration and verified WordPress behavior.
  • Verification: Guest and authenticated end-to-end journeys after alignment and explicit execution authorization.

2026-07-30T18:30:00Z — Question Q-006

Decision: Choose anonymous quiz and bearer-link retention.
Why it matters: Access tokens are bearer credentials; retention defines the privacy and exposure window.
Recommendation: 24 hours.
Options presented: 24 hours; 7 days; session-only.

2026-07-30T18:30:00Z — Decision/Conflict D-007

Choice: “for ever unless removed manually”
Owner: user.
Exact answer: “for ever unless removed manually”
Status: conflicts with current source behavior.

Evidence

  • includes/ExposureSettings.php:821-824 clamps guest_quiz_hours to 1–720.
  • includes/Frontend/CraftHandler.php:118-128 clamps generated guest expiry to 1 hour–7 days.
  • includes/Frontend/CraftHandler.php:52-74 hourly cleanup deletes expired ephemeral quizzes.

Implication

  • Current anonymous self-service cannot retain generated quizzes/links forever.
  • Anonymous bearer links have no durable owner identity for a safe self-service delete control.
  • This needs a deliberate policy/feature decision before implementation.

2026-07-30T18:30:00Z — Question Q-007

Decision: Reconcile durable artifacts with anonymous access.
Why it matters: Perpetual bearer links and unowned anonymous objects create an indefinite disclosure, storage, and manual-deletion problem.
Recommendation: Persistent artifacts only for signed-in owners; anonymous artifacts cap at 30 days.
Options presented: Account-owned persistence plus 30-day guests; 30-day maximum for everyone; redesign permanent anonymous artifacts with an admin/manual recovery model.

2026-07-30T18:30:00Z — Decision D-007

Choice: Account-owned persistence.
Owner: user.
Exact answer: “Account-owned persistence”
Rationale: Durable quizzes need a signed-in owner who can manually remove them; anonymous self-service remains available within a bounded retention window.

Rejected

  • A 30-day maximum for every artifact.
  • A new permanent anonymous-ownership/recovery model.

Implied consequences

  • Signed-in owners retain and manually delete their saved quizzes indefinitely.
  • Anonymous generated quizzes and bearer links are capped at 30 days.

Traceability

  • Requirement/AC: Account ownership controls durable self-service; anonymous links do not become perpetual credentials.
  • Implementation constraint: The existing clamp supports 30 days exactly (720 hours); retain that maximum rather than inventing permanent anonymous artifacts.
  • Verification: Account ownership/delete and anonymous-expiry behavior after implementation authorization.

2026-07-30T18:30:00Z — Question Q-008

Decision: Choose the target-site ZIP integrity standard.
Why it matters: A private deployment archive still modifies a public site, but the bench lacks the documented canonical build/source-archive tooling.
Recommendation: Recover canonical source/toolchain and create a reproducible checksumed private deployment package, without publishing it.
Options presented: Recover canonical pipeline; separate verifiable private deployment package; manual one-off ZIP.

2026-07-30T18:30:00Z — Decision D-008

Choice: Recover canonical pipeline.
Owner: user.
Exact answer: “Recover canonical pipeline”
Rationale: The private target-site ZIP must be reproducible and checksumed without being published to a marketplace or repository.

Rejected

  • A separately verified private package without canonical pipeline recovery.
  • A manual one-off ZIP from the bench.

Implied consequences

  • Canonical source, immutable commit, locked toolchain, and documented packaging controls are an external prerequisite.
  • No target-site ZIP may be represented as ready before those prerequisites are recovered and verified.

Traceability

  • Requirement/AC: Private deployment artifact is reproducible, checksumed, and traceable while remaining unpublished.
  • Implementation constraint: Do not reconstruct the absent release toolchain in the bench.
  • Verification: Canonical pipeline evidence and target-site package/install verification after alignment and explicit execution authorization.

2026-07-30T18:30:00Z — Question Q-009

Decision: Choose public operator/contact/policy-page posture.
Why it matters: Full self-service and approved external features require an accountable public site identity and configuration-true notices, while best effort means no hidden SLA promise.
Recommendation: Project identity, monitored contact, best-effort statement, Privacy and Terms/acceptable-use pages.
Options presented: Full transparent posture; identity and Privacy only; no public support/policy posture.

2026-07-30T18:30:00Z — Decision D-009

Choice: Keep the plugin scope bare minimum because the running target project already handles public operator identity, contact, Privacy, Terms, and best-effort posture.
Owner: user.
Exact answer: “this is all allready handled by the running project allready so do the bare minimum within the plugin scope”
Rationale: Avoid duplicating site-level accountability/policy pages inside QuizWizz; ensure only that enabled QuizWizz configuration is compatible with those existing policies.

Rejected

  • Creating duplicate plugin-owned public support, Terms, or Privacy pages.

Implied consequences

  • The target project, not the plugin, owns public legal/contact/support presentation.
  • Plugin-scope work remains responsible for accurate configuration, feature disclosure inputs, and safe behavior.

Traceability

  • Requirement/AC: No duplicate public policy surface is added by the plugin.
  • Implementation constraint: Verify target-site policy/configuration alignment before enabling AI or remote banners.
  • Verification: Read-only policy/configuration crosswalk after canonical source access and explicit execution authorization.

2026-07-30T18:30:00Z — Question Q-010

Decision: Locate the canonical source repository and locked build pipeline.
Why it matters: The selected private-package integrity model cannot be performed from the bench, which lacks the documented locks and packaging scripts.
Recommendation: Provide an authorized private canonical clone path or repository URL.
Options presented: Existing local clone; private remote repository; unavailable/not yet recoverable.

2026-07-30T18:30:00Z — Decision D-010

Choice: WRDP is the master QuizWizz project.
Owner: user.
Exact answer: “wrdp”
Rationale: The master source is already on this server in the current WRDP project, rather than in another private clone or remote repository.

Implication

  • The absent lockfiles/toolchain/package scripts are master-project gaps to establish, not assets to retrieve from elsewhere.
  • The previously selected reproducible private-package path remains valid but requires a minimal packaging foundation within WRDP.

Traceability

  • Requirement/AC: WRDP becomes the controlled source baseline for a private, unpublished target-site package.
  • Implementation constraint: No repository/marketplace publication and no false claim of release eligibility.
  • Verification: Source baseline, package checksum, target-site install, and rollback evidence after explicit authorization.

2026-07-30T18:30:00Z — Question Q-011

Decision: Authorize a separate build environment for the private target-site package. Why it matters: WRDP is the master source but its repository rules prohibit reconstructing/running the absent release toolchain on this bench. Recommendation: Use a new isolated build environment from the WRDP source, with pinned tools and no production credentials. Options presented: New isolated build environment; existing authorized builder; defer packaging.

2026-07-30T18:30:00Z — Decision D-011

Choice: Defer packaging.
Owner: user.
Exact answer: “Defer packaging”
Rationale: No separate build environment, private ZIP, or target installation will be created in this phase.

Implied consequences

  • The plan remains limited to plugin-scope readiness alignment.
  • Private package creation stays a conscious deferred item, not an implied next step.

2026-07-30T18:30:00Z — Finding F-011

Statement: Anonymous AI requests are refused by current source; AI requires an authenticated user with the required capability.
Status: confirmed
Evidence grade: E2
Source: wp/wp-content/plugins/quizwizz/includes/Ai/RequestContext.php:24-40; includes/Ai/OpenRouterClient.php:38-50.
Implication: “Full self-service” does not currently imply guest access to AI; that is a separate user-owned capability decision.

2026-07-30T18:30:00Z — Question Q-012

Decision: Choose anonymous-AI capability.
Why it matters: Public guest AI changes the anonymous abuse, cost, and third-party data boundary.
Recommendation: Keep AI authorized-user-only.
Options presented: Authorized users only; public guest AI; AI fully disabled.

2026-07-30T18:30:00Z — Decision D-012

Choice: Preserve authorized-user-only AI for now; require a future admin setting that can explicitly allow unregistered visitors to use a front-end QuizWizz AI assistant for finding or crafting quizzes.
Owner: user.
Exact answer: “for now the reccomended. but it should be possible to toggle this in backend admin settings to allow even unregistered users to use the chat bubble quizz wizzard ai assistent front end chat to find or craft a quizz.”
Rationale: Default posture remains controlled; the desired future public assistant must be a separately configured capability rather than an accidental consequence of full self-service.

Implied consequences

  • Do not implement or enable the assistant during alignment.
  • The assistant is a new feature, not merely a setting change: it requires frontend UX, server-side intent/quiz-craft contract, guest authorization/rate/cost control, provider policy, privacy disclosure inputs, and audit/rollback behavior.

2026-07-30T18:30:00Z — Research branch RB-001

Statement: User requested connector evaluation: use the WordPress Connectors capability, OpenRouter, or both with a toggleable default and fallback “like pros.”
Status: open research.
Evidence grade: E1
Source: User request; wp/wp-admin/options-connectors.php:13-38 confirms the admin screen exists, requires manage_options, and is unavailable unless the AI client class and built page renderer are present.
Implication: Provider/fallback design is not settled until installed Connector capability and the existing QuizWizz AI boundary are mapped.

2026-07-30T19:00:00Z — Finding F-013

Statement: WordPress 7.0.2 Connectors provides connector credential management and an AI-client registry, but no configured compatible provider was evidenced on this installation. It does not provide QuizWizz authorization, guest abuse controls, budgets, chat state, or execution-time fallback. Status: confirmed Evidence grade: E3 Source: wp/wp-admin/options-connectors.php; wp/wp-includes/{connectors,ai-client}.php; installed registry inspection. Implication: Connectors may become a provider adapter, but cannot replace a QuizWizz-owned assistant policy.

2026-07-30T19:00:00Z — Finding F-014

Statement: QuizWizz AI currently calls OpenRouter directly for authenticated, capability-authorized users only; it has no front-end chat/search assistant. A hypothetical guest context would collapse visitors to actor_id=0, while the existing ledger has one shared date-only budget. Status: confirmed Evidence grade: E2 Source: includes/Ai/{OpenRouterClient,RequestContext,AiBudget,Ability}.php; includes/Installer.php; reviewer audit. Implication: Guest AI is a new feature that needs its own cookie-bound identity, guest-only scope, bounded guest budget, and readiness gate. It must not reuse the present substrate unchanged.

2026-07-30T19:00:00Z — Finding F-015

Statement: Core AI preferences may silently select a first discovered provider/model when no preference matches, and a generation is single-shot without fallback retry. Status: confirmed Evidence grade: E2 Source: wp/wp-includes/php-ai-client/src/Builders/PromptBuilder.php:812-836,1181-1185. Implication: A “both providers” design must explicitly pin provider and model and implement any narrow fallback inside QuizWizz, sharing one logical budget reservation.

2026-07-30T19:00:00Z — Question Q-013

Decision: Choose the future Quiz Wizzard provider policy. Why it matters: Connectors does not cover the requested assistant end-to-end and is not presently backed by a configured provider. Automatic provider preference/fallback is unsafe and non-deterministic. Recommendation: Start the future authorized-only assistant with a direct, explicitly pinned OpenRouter provider/model. Add a Connector adapter only after a compatible provider is installed and verified; enable one narrow plugin-owned fallback only after both routes have been tested. Options presented: Direct OpenRouter only; Connector-backed provider once available; explicit hybrid with a pinned primary and one narrow fallback.

2026-07-30T19:10:00Z — Decision D-013

Choice: Future Quiz Wizzard design starts with direct OpenRouter and an explicitly pinned provider/model. Connector support is deferred until a compatible provider is installed and verified. Owner: user. Exact answer: “OpenRouter first” Rationale: OpenRouter is the only evidenced configured route. Connectors is credential/registry infrastructure, not a presently usable provider or an assistant framework.

Rejected

  • Connector-only design before a compatible provider exists.
  • Unpinned automatic provider selection.
  • Automatic multi-provider fallback.

Implied consequences

  • No automatic use of WordPress Connector candidates.
  • If a fallback is later approved, QuizWizz must own one bounded transient-failure retry, share one logical budget reservation, and record the resolved provider/model.
  • The next decision is whether anonymous users, when explicitly enabled, get finding only or also cost-bearing unsaved draft crafting.

2026-07-30T19:10:00Z — Question Q-014

Decision: Choose anonymous Quiz Wizzard capability when its future admin toggle is enabled. Why it matters: Finding public quizzes can be served from the existing bounded library projection; draft crafting sends anonymous free text to a provider and needs distinct guest identity, budget, audit, readiness, and review controls. Recommendation: Finding already published quizzes only. Options presented: Finding only; finding plus unsaved draft crafting under the stronger guest-AI gate.

2026-07-30T22:07:17Z — Finding F-016

Statement: The WRDP edge policy is now in force: nginx denies logs, dumps, archives, editor droppings, dotfiles except ACME, uploaded/upgrade PHP, XML-RPC, and legacy packaging files; it also applies app security headers and an operator-exempt wrdp_login credential-endpoint ceiling at 1r/s burst=10 returning 429. Status: confirmed Evidence grade: E3 Source: /etc/nginx/sites-available/wrdp.loca.zone; /etc/nginx/snippets/wrdp-proxy.conf; /etc/nginx/snippets/security-headers-app.conf; /etc/nginx/conf.d/wrdp_limits.conf; live ingress checks. Implication: The previous absence of path-deny, security-header, and login-ceiling evidence is closed for this bench; WAF/bot policy and proxy log/alert retention remain separate future operations controls.

2026-07-30T22:07:17Z — Finding F-017

Statement: Apache mod_remoteip already rewrites REMOTE_ADDR to the real client address for the 172.31.0.0/16 compose network; nginx now forwards X-Forwarded-For: $remote_addr; RateLimiter::client_ip() returns REMOTE_ADDR directly because quizwizz_trusted_proxies has no subscriber. Status: confirmed Evidence grade: E3 Source: /etc/apache2/conf-available/remoteip.conf; apache2ctl -M; docker network inspect wrdp_wrdp_net; includes/RateLimiter.php:160-189; container access logs. Implication: The plugin’s per-network rate limiting depends on mod_remoteip; the concern that every visitor shares the bridge gateway bucket does not apply to this bench, and no trusted-proxy subscriber is needed.

2026-07-30T22:07:17Z — Finding F-018

Statement: The public debug-log exposure is remediated: WordPress writes the live log outside the document root at /var/log/wp/debug.log, https://wrdp.loca.zone/wp-content/debug.log now returns 404, and a planted in-docroot probe file also returned 404. Status: confirmed Evidence grade: E3 Source: docker-compose.yml; logs/debug.log; curl -I https://wrdp.loca.zone/wp-content/debug.log; planted /wp-content/deny-probe.log check. Implication: R-001 is remediated for the bench; the health probe keeps the public path denial as a regression guard.

2026-07-30T22:07:17Z — Decision D-014

Choice: Finding plus unsaved crafting. Owner: user. Exact answer: Finding plus unsaved crafting Rationale: The future assistant may be useful as a public finder and draft helper, but anonymous cost-bearing generation is only acceptable behind a hard gate rather than by reusing the present authenticated AI substrate.

Rejected

  • Reusing actor_id 0 or logged-out nonces as a guest identity.
  • Sharing the authorized-user daily budget with anonymous visitors.
  • Allowing openrouter/auto or any unpinned provider/model.
  • Letting any guest path persist or publish generated content.

Implied consequences

  • Cookie-bound guest identity distinct from actor_id 0.
  • Guest-only operation allowlist.
  • Separate guest daily budget defaulting to zero and keyed independently of the site budget.
  • Explicitly pinned provider and model, with openrouter/auto refused.
  • No guest path reaches persistence or publishing.
  • Bounded audit record.
  • Guest readiness predicate surfaced in Site Health.

2026-07-30T22:07:17Z — Decision D-015

Choice: Defer the external-data and maintenance runbook. Owner: operator / release owner. Exact answer: deferred external-data/runbook decision. Rationale: Remote-banner sources, abuse and budget caps, package verification, and best-effort cadence remain public-launch prerequisites, but they are not authorized implementation work in this pass.

Rejected

  • Treating the hardening pass as implicit approval for external data, remote banners, packaging, or maintenance promises.

Implied consequences

  • The runbook remains a named open prerequisite rather than scope creep.
  • No external-data or package-verification claim may be published until the deferred decision is made and verified.

2026-07-30T22:07:17Z — Question Q-015

Decision: Authorize building the future Quiz Wizzard assistant under the settled guest-AI gate, or keep it deferred. Why it matters: D-014 settles the capability shape but does not authorize implementation, provider spend, guest privacy disclosure, or runbook work. Recommendation: Keep the assistant deferred until the owner explicitly accepts the seven-part gate, provider/privacy disclosure work, and operations runbook. Options presented: Authorize implementation under the full gate; keep the assistant deferred.