6 Commits
Author SHA1 Message Date
twooey 1020a496ab Fix seven medium-severity bugs from the full-session code review
- SupplierOffer::insert(): now checks $wpdb->insert()'s return value and
  throws, matching Work/Edition/Isbn (the one Catalog class that hadn't
  been hardened this way). Work::set_product_id() gets the same treatment
  (was flagged low-severity but same fix, bundled here) — a real update
  failure now counts as a per-work sync failure instead of silently
  leaving a stale wc_product_id pointer.

- SupplierOffer: fetched_at was written via current_time('mysql') (site-
  local) while expires_at (SyntheticOfferGenerator) is written in UTC, and
  best_offer_for_isbns() compared against site-local time too — a mismatch
  masked today only because dev's gmt_offset is 0. Switched both writer and
  reader to current_time('mysql', true) (UTC). Verified the read path
  still finds all active offers correctly under a simulated -5 (US
  Eastern) offset, not just at offset 0.

- HardcoverAdapter: rate-limit throttling moved from "once per work" (in
  Commands.php) to "once per actual HTTP request" (inside query() itself).
  find_book()'s ISBN-then-title/author fallback can fire two real requests
  per work — under the old scheme both shared one throttle sleep, roughly
  doubling the real request rate against a beta API. query() also now
  retries network errors/5xx/429 up to 3x (mirroring
  OpenLibraryAdapter::get_with_retry()), while a GraphQL-level `errors` field
  or other 4xx throws immediately (retrying a rejected query can't fix it).
  Commands.php adds a 5-consecutive-failure circuit breaker so a bad token
  or a wrong field in the still-unverified schema can't silently burn
  through the whole catalog with zero progress. Verified all of this
  directly against Hardcover's real API with a deliberately invalid token:
  5 fast (non-retried) 401s, correct abort message, and confirmed the
  failed works were NOT marked synced (so a real token can retry them).

- restore.sh: now drops and recreates the target database before restoring
  the dump, and clears the uploads directory before extracting the
  archive — previously both restored on top of existing state, so a stray
  table or file NOT in the backup would silently survive a restore drill.
  Verified end-to-end against a real local staging stack: planted a stray
  table and a stray upload file after taking a backup, ran restore.sh, and
  confirmed both were gone afterward while the actual backed-up data (20
  works, a known upload file) came back correctly. Also fixed a real
  permission gap hit during that same test: a fresh volume's uploads dir
  is root-owned until something chowns it, which broke the new www-data
  clear step — now clears as root and chowns to www-data afterward, which
  also means restore self-heals the exact root-owned-uploads class of bug
  fixed earlier this session for the cron sidecar.

- poll-deploy.sh: added a non-blocking flock so a deploy that runs longer
  than the cron interval can't have a second poll fire mid-deploy and race
  its git checkout/reset against the same live working tree. Verified: a
  concurrent run correctly skips instantly while the lock is held, and
  proceeds normally once it's released. (Full atomicity of the live PHP
  file swap under real traffic is a bigger architectural question —
  blue-green or symlinked releases — flagged to the user rather than
  attempted here.)

- backup.sh: now also archives .env.<environment> itself (chmod 600) and
  includes it in the off-host rclone sync alongside the DB dump and
  uploads archive. Every API key and both DB passwords previously lived
  only on the host in this one gitignored file — losing the host lost all
  of it even with DB/uploads backups intact.
2026-08-27 15:50:49 -04:00
twooeyandClaude Sonnet 5 a782f880bc Week 2: catalog schema, Gutenberg importer, pricing engine, membership shipping
Builds bookstore-core's first real business logic (design doc §02-§05,§07),
replacing the plugin stub with:

- Schema: bsc_work/edition/isbn/cover_variant/supplier_offer/member tables
  via dbDelta, with a versioned upgrade path.
- GutenbergImporter: imports Project Gutenberg's live bulk catalog as
  synthetic staging data. Deterministic checksum-valid ISBN-13s (there are
  no real ISBNs in PG data) keep re-imports idempotent.
- SyntheticOfferGenerator: the GutenbergTestAdapter of §04 — realistic
  condition/stock/price distribution with deliberate out-of-stock/stale/
  discontinued cases for later exception-path testing.
- PricingEngine: the §05 margin formula, verified against the design
  doc's own worked example ($6.00 + $3.99 -> $14.99 exactly).
- ProductSync: one WooCommerce product per Work, never per ISBN (§03),
  idempotent (verified: re-sync of 2000 works produces 0 duplicates).
- BSC_Free_Shipping: a real WC_Shipping_Method (WooCommerce's built-in
  Free Shipping only supports one static threshold, not membership-
  conditional), verified through actual browser-session cart flows in
  both directions, not just unit calls.

Found and fixed one real data-integrity bug while scale-testing: PG's
Authors field lists every contributor for anthology works, overflowing
primary_author's column — Work::insert() was failing silently (Catalog
insert methods never checked $wpdb->insert()'s return value), while the
following Edition/Isbn inserts for that same row went ahead anyway and
attached to whichever work_id was last successful. Fixed at the root:
inserts now throw on failure, the importer takes just the first author
(matching the column's actual semantic intent), and the import loop
catches per-row failures so one bad title can't abort a bulk run.

Verified end-to-end against a real 2000-title import: exact work/edition/
isbn/product count parity, no duplicates on re-run, real HTTP cart tests
for both shipping thresholds, live storefront search.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 13:13:38 -04:00
twooeyandClaude Sonnet 5 3876a6ba30 Fix DB password corruption via Docker secrets file mechanism
The reported bug (a generated password containing "$BRjTx3tlmSpz" got
silently blanked, breaking the DB connection) is the same Compose
interpolation issue as the earlier bcrypt hash, but this time in fields
that are genuinely user-chosen and can't just be avoided by convention.

Switched DB_PASSWORD/DB_ROOT_PASSWORD to Docker's official `_FILE`
secrets convention (MARIADB_PASSWORD_FILE / WORDPRESS_DB_PASSWORD_FILE),
backed by Compose's native `secrets:` mechanism: deploy.sh writes the raw
value to secrets/<env>/db_password, and the container reads that file
directly — the value never passes through Compose's ${VAR} interpolation
at all. Verified end-to-end with an actual `$`-containing password,
including a full deploy → backup → restore → still-serving round trip.

Also fixed along the way (found while actually testing, not assumed):
- Makefile never exported ENVIRONMENT, so `make up` alone (bypassing
  deploy.sh) would have left the new secrets path unresolved.
- deploy.sh chmod'd the secret files 600, unreadable by the container's
  own UID (www-data) — fixed to 644, relying on the containing directory
  (700) to keep other host users out instead.
- backup.sh/restore.sh still called `mysqldump`/`mysql`, which don't
  exist in the mariadb:11 image under those names — renamed to
  mariadb-dump/mariadb. (This means neither script had actually
  succeeded before now; both are verified working end-to-end here.)

The supplier/payment API keys remain passed the old way — nothing reads
them yet (bookstore-core is still a stub), so there's no live bug to fix
there; noted in .env.example that the same _FILE pattern should be used
once that code exists.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 11:36:29 -04:00
twooeyandClaude Sonnet 5 cd48f85a47 Remove staging basic-auth wall — box is LAN-only
Staging runs on a private-network VM, not reachable from outside, so the
HTTP basic-auth layer was unnecessary defense-in-depth. Removing it also
lets the Caddyfile drop the render-around-Compose workaround entirely
(that workaround existed specifically because Compose's interpolation
mangles a bcrypt hash) — the noindex header and blog_public=0 stay, since
those guard against search-engine indexing, a separate concern from
network-level access.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 11:23:35 -04:00
twooeyandClaude Sonnet 5 b43852e733 Switch deploy pipeline to Gitea polling; fix env-parsing and volume-isolation bugs
- Replace the bare-repo post-receive hook with deploy/poll-deploy.sh: Gitea
  and the Docker hosts are separate machines, so each box polls its branch
  via host crontab instead of needing an exposed webhook receiver.
- Add Blocksy theme + Blocksy Companion auto-install to deploy.sh (free
  tier; the paid Book Store starter site still needs a manual license step).
- Fix deploy.sh/backup.sh/restore.sh sourcing .env files as bash: a bcrypt
  hash's `$2a$14$...` shape breaks under `set -u`. Replaced with
  deploy/lib/env.sh, a literal (non-executing) KEY=VALUE reader.
- Fix docker compose itself mangling the same kind of value: both
  `environment: ${VAR}` and `env_file:` run values through Compose's
  interpolation, which silently blanks `$identifier`-shaped substrings.
  The staging basic-auth hash is now rendered directly into the Caddyfile
  by deploy.sh, bypassing Compose's variable system entirely.
- Fix dev/staging/production silently sharing one Compose project (and
  therefore one db_data volume) by pinning an explicit -p per environment.
- cron and wordpress now share one environment anchor so they can't drift
  apart again (cron was silently missing WORDPRESS_CONFIG_EXTRA before).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 10:10:12 -04:00
twooeyandClaude Sonnet 5 c9d637c907 Week 1 infrastructure: Docker environments, deploy pipeline, bookstore-core scaffold
Docker Compose environments for dev/staging/production (MariaDB, Redis,
Caddy, Action Scheduler cron sidecar), an idempotent deploy script,
git-hook-based deploy pipeline, backup/restore scripts, and the
bookstore-core plugin stub with WooCommerce HPOS compatibility declared.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 09:50:18 -04:00