# Issues register Last swept 2026-09-15. ## P1: blocks the launch - **Production edge for the login: Caddy trusted_proxies on the droplet, Cloudflare cache bypass for the auth paths, Bot Fight Mode off** (P1; owner E; raised 2026-09-10 by planning 10 Sep; id `issue-production-edge-for-the-login-caddy-trusted-proxies-on-t`) The login throttle keys on CF-Connecting-IP through Caddy's trusted_proxies; without the same block on the droplet's Caddy every visitor shares one key and ten wrong attempts lock everyone out. The zone's cache rules must bypass /api/*, /login, /forgot, /welcome/*, /reset/*, /account*, /admin* on both zones, Bot Fight Mode and managed challenges must stay off so the login POST is never challenged, and the domain password comes off only after the curl list in the accounts plan section 7 holds. Add to the E7 checklist. Gates: E7 (blocking) — the work it gated has gone ahead under the assumption; settling it now avoids a costlier change later - **Dubai refuses our reader by name at the Akamai edge** (P1; raised 2026-09-03 by Stream A; id `issue-dubai-refuses-by-name`) Since 3 Sep: our declared identity gets 403, a generic browser identity gets 200, robots.txt refused too, error page from Akamai. Last good run 22 Aug with the same identity, so their rules changed. Dubai is about 39 percent of launch products and 77 percent of barcodes. Deliberately not bypassed. Path decided: the identity page becomes its own static project, the reader is repointed once it serves, the ask goes to Dubai when you judge the relationship ready, and Dubai launches on dated 21 Aug prices. Open: the hostname decision and your Dubai conversation. ## P2: silently corrupting data or blocking a page - **The mail lines (MAIL_PROVIDER, MAIL_FROM, RESEND_API_KEY) need the app-only env file before they are set: the compose split, with this review** (P2; owner W; raised 2026-09-11 by Stream R2; id `issue-the-mail-lines-mail-provider-mail-from-resend-api-key-ne`) T6 wired mail to the end (the Resend provider, the daily caps in email_sends, the notification digest, the mail preference) and set nothing: every path is inert until the three MAIL_* lines exist, and they must not go into .app.env, which docker-compose.yml hands to the database container as well (env_file on both services). W3's split is the compose change; the security review Stream R2 owes it is here so W3 can act on it without a second reading. Review. Port binding: unchanged (the app stays on 172.17.0.1:PORT, the database publishes nothing). Authentication: unchanged. Network exposure: the app makes one new outbound HTTPS call per message to api.resend.com with the key in the Authorization header only; no inbound path. Credential storage: RESEND_API_KEY is a bearer credential able to send mail as the site; it belongs in a file only the app container and rian read (0600, the srv-gateway ACL as for .app.env), referenced as a second env_file on the app service only, never on db or browser; the browser sidecar keeps no env_file at all. Container isolation: no new capability, no mount. Automated execution: notify digest runs from host cron, reads the database, sends at most 40 mails per person per day and 25 invites per host, and cannot be triggered from a request; the caps are the bound if the key leaks. Blast radius of a leak: mail sent in the site's name until the key is rotated at Resend; rotation is one line and a container recreate. After the change: srv-gw security-audit. Proposed compose shape for W3 (not applied by R2): under services.app add a second env_file entry, .app-only.env, holding only the MAIL_* lines (and any later app-only secret); .app.env keeps the database lines both containers need. Stage .app-only.env with REPLACE_WITH_ placeholders, chmod 600 plus the gateway ACL, and add it to .gitignore beside .app.env. Nothing else in the compose file moves. Options: W3 splits the env file as proposed (assumed) · keep one env file and accept that the database container reads the mail key *Proceeding under:* the app-only env file lands with W3; until then no MAIL_* line is set anywhere Gates: W3 (costly) — blocks W3 (An app-only env file in compose so the database container reads no app secret: security review, the change staged and audited, the droplet twin as a checklist for rian), due 2026-09-17 See `main/docs/RUNBOOK.md` See `main/app/cli_notify.py` - **No scheduler and no freshness alarm yet** (P2; owner E; raised 2026-08-27 by issues register; id `issue-scheduler-freshness-alarm`) Prices must be current in late September. Collection stays hand-run, but the nightly audit, verify after any collection, the weekly verify, and an alert when a store returns far less than its last run (the Heathrow lesson) all need a cron home, decided by where the collectors run. Stream E task E5. Gates: E5 (blocking) — the work it gated has gone ahead under the assumption; settling it now avoids a costlier change later - **The database container reads every line of .app.env; split an app-only env file before any mail or Google secret lands** (P2; owner E; raised 2026-09-10 by planning 10 Sep; id `issue-the-database-container-reads-every-line-of-app-env-split`) docker-compose.yml gives the db service env_file: .app.env, so ACCOUNT_OWNER and any future MAIL_API_KEY or Google secret land in the postgres container's environment. R1 adds no new secret by design. Before R2's mail key: a separate app-only env file (or a db-only one) in compose, a security review first, then srv-gw security-audit; the same shape on the droplet. Also tighten .app.env, but not with a plain chmod 600: the gateway's docker compose reads env_file as srv-gateway through the project group's ACL, and chmod 600 sets the ACL mask to nothing so srv-gw deploy fails at config load. Use setfacl -b .app.env && chmod 600 .app.env && setfacl -m u:srv-gateway:r .app.env, verify with sudo -u srv-gateway test -r .app.env, and note that srv-gw fix-permissions re-widens it (ideas.md 2026-08-04). The RUNBOOK's mode wording carries the same recipe. Gates: E7 (costly) — the work it gated has gone ahead under the assumption; settling it now avoids a costlier change later - **identity_mode is a column; nothing enforces the consent rule** (P2; owner A; raised 2026-09-09 by Stream N; id `issue-identity-mode-is-a-column-nothing-enforces-the-consent-r`) The rule (agents.md, build plan section 4 item 11, COLLECTORS.md): a source runs in a browser-like identity only when its permission_record names who agreed, when and how, and without the record the collector refuses to switch. Migration #1 added sources.identity_mode and permission_record; no code reads either (grep across app/ and tests/ finds only the model). Today that is safe by absence, since every collector sends the declared identity and no path can switch. The refusal itself must exist before any switch does: fetch() (or the collector base) reads the source's identity_mode, sends the browser-like headers only when permission_record is non-empty, and raises otherwise, with a test that a source set to browser_like and no record is refused. - **Uploads land root-owned on the host because the app container runs as root** (P2; owner E; raised 2026-09-09 by Stream N; id `issue-uploads-land-root-owned-on-the-host-because-the-app-cont`) Noted in the 5 Sep to-do page handoff and never filed: the container's process runs as root, so a file Adam hands in through /todo is written to the mounted uploads/ directory owned by root, and neither rian nor a session can move or delete it without sudo. Fix on the infrastructure side: run the app as a non-root user in the Dockerfile with the uploads directory chowned to it (or a matching uid on the host); the production droplet should start that way rather than inherit the habit. Check by behaviour: a test upload lands owned by the app user. - **No command imports Adam's brand images from a folder** (P2; owner A; raised 2026-09-09 by Stream N; id `issue-no-command-imports-adam-s-brand-images-from-a-folder`) Stream A's Wave 2 handoff listed 'app.cli images import ' as not done, and it still does not exist: python -m app.cli images only enriches from the openly licensed source. Adam's official product images arrive in the shared Drive folder named by brand and product (/todo row 8). The command should take a directory, match each file to a product (barcode in the name first, then brand and name), store it as first-party imagery with provenance 'brand' and never overwrite a human-set image; a dry run lists the matches. - **2,422 liquor products carry no category, so they sit on no shelf** (P2; owner A; raised 2026-09-10 by Stream E; id `issue-2-422-liquor-products-carry-no-category-so-they-sit-on-n`) Counted on staging 11 Sep: 2,422 products with vertical liquor and category NULL (881 of them at no visible airport). They are searchable and appear in airport and brand lists but on no category shelf and in no menu count. The categories backfill only fills rows its rules recognise; the rest need either wider rules (the retailer's own family label is stored in raw_records) or a rederive pass. Worth doing before B6's category pages, which would otherwise undercount every shelf. - **When sponsor creative arrives, the server-rendered article and airport pages must follow the browser's layout** (P2; owner B; raised 2026-09-11 by Stream C; id `issue-when-sponsor-creative-arrives-the-server-rendered-articl`) The server copies of pages (seo.py article_body, airport_body) draw every page as it is with no sponsor creative. Once creative is added to web/src/lib/sponsors.ts (SPONSORS or NATIVE_SPONSORS), two layouts change in the browser only: an article with the skyscraper gets a right-hand rail (the text is no longer centred), and the airport shelf with its native tile lists 23 bottles per page instead of 24. If the mirrors are not updated in the same deploy, those pages shift visibly as they load and crawlers see 24 bottles per airport page (and different page boundaries) where shoppers see 23. Fix when the first creative lands: move the active-placement registry somewhere both sides can read (for example a JSON file the server loads and the SPA imports, or flags in the shell like window.__DFP_FLAGS__), then have article_body draw .article-page__layout--rail and airport_body page by 23 whenever the matching placement has creative. Previews switched on from /settings are per browser and never need the mirror. See `main/docs/CLIENT-SURFACES.md` - **Before launch the footer needs privacy, terms and contact pages, and none exist yet** (P2; owner C; raised 2026-09-11 by Stream C; id `issue-before-launch-the-footer-needs-privacy-terms-and-contact`) The live-ready footer (0.44.0) links only pages that exist: the shop, the busiest airports, articles and the price data. A site that collects names and emails for its newsletter needs a privacy policy linked from every page before go-live, and a terms of use and a way to contact us are expected in a footer. Build the three pages and add a Legal column (or bottom-bar links) once Adam has approved the wording; the consent sentence decision on the subscribe form is the same conversation. - **A litre pattern reads the 5 in a name like N°5 L'EAU as five litres** (P2; owner A; raised 2026-09-11 by Stream M; id `issue-a-litre-pattern-reads-the-5-in-a-name-like-n-5-l-eau-as`) main/app/services/normalize.py parse_size and parse_size_ml: the litre pattern (\d+)\s*l\b matches '5 L' inside "N°5 L'EAU 100ml" (the apostrophe is a word boundary), so the Bogota and Panama Shopify listings of CHANEL N°5 L'EAU 100ml (listing tiles say '100 ml') are stored as size 5.00 l, 5000 ml, and can never match the other shops' 100 ml row. Seen on the /collectors Listings view, 'Size differs' filter, 11 Sep staging copy. Suggested fix: try ml and cl before the litre patterns, or refuse a litre token followed by an apostrophe or a letter; then backfill implausible_sizes (5000 ml is over the beauty ceiling) and rederive. A test with the real name belongs in tests/test_normalize.py. - **Thirteen Extime products are named No, Yes or nothing** (P2; owner A; raised 2026-09-11 by Stream M; id `issue-thirteen-extime-products-are-named-no-yes-or-nothing`) On the 11 Sep staging copy, 13 alive products carry the name 'No', 'Yes', 'N/A' or an empty string; eleven are Plisson at CDG (ids 11374, 11402, 11405, 11507 and seven more; URLs like extime.com/en/paris/product/beard-oil-105585111, natural-shaving-cream-tube-105585117). The Extime collector reads a field that holds a yes/no flag for these pages instead of the product name (the URL slug carries the real name). Seen on the Listings view and as a line called 'No' with eleven products under Plisson. Suggested fix in collectors/extime.py: refuse a name that is a bare yes/no or empty and fall back to the JSON-LD name or the slug; a test with the real fragment; then rederive. ## P3: should fix before Cannes - **Extime is Paris (CDG and Orly together), not CDG alone** (P3; raised 2026-09-03 by Stream A; id `issue-extime-paris-not-cdg`) The storefront is one Paris tenant; the only terminal signal is the combined value and there is no per-airport sitemap, so the location is named for both with code CDG. If Adam needs CDG-only pricing that is an unmet requirement to raise with him, not a bug. Gates: P6 (costly) — blocks P6 (Delivery walkthrough with Adam), due 2026-09-18 - **Watch: the four Shopify shops refused us on 4 Sep and accepted us on 5 Sep** (P3; owner Q; raised 2026-09-05 by planning session; id `issue-watch-the-four-shopify-shops-refused-us-on-4-sep-and-acc`) On 4 Sep all four answered 403 to robots.txt for our identity; on the 5 Sep afternoon refresh, run with the identity link repointed to bot.dutyfreeprofessor.com, all four served robots.txt and their product feeds and collected normally. Either the refusal was transient or the platform's protection scored the old, non-resolving identity link. Nothing to do unless it recurs; if verify sees BLOCKED on any of them again, note whether the identity page was reachable at the time. - **Watch: Gratien & Meyer at JFK, $77 against about $21 in Europe** (P3; raised 2026-08-25 by rian; id `issue-gratien-meyer-jfk`) Both prices verified real on the retailer's pages. Across 304 shared JFK/Europe products the median ratio is 1.07 and this bottle is the maximum at 3.74, so almost certainly the retailer's own entry error. Kept on its page (it is the published price), excluded from featuring by the corroboration rule. Does it correct on the next JFK crawl? - **Per-size listings from configurable tiles carry no barcode** (P3; owner A; raised 2026-08-25 by rian; id `issue-variant-listings-no-barcode`) A size row emitted from a configurable tile has no barcode, so image enrichment cannot attach a photo and cross-shop matching falls back to names, which is what splits. Possible fix: read per-variant barcodes from the tile's configuration data when present. - **Ghost listings at stores that could not be re-read** (P3; owner A; raised 2026-08-25 by rian; id `issue-ghost-listings`) The 25 Aug purge removed superseded plain listings only where a per-size sibling exists at the same store; stores whose tiles could not be re-read keep old listings, so a few barcode-less ghosts survive at hidden locations. Self-heals when those stores next crawl clean; the same purge pattern covers the reverse case if a tile ever goes from multi-size to single-size. - **Extime: a few paths handled defensively but never seen for real** (P3; owner A; raised 2026-09-03 by Stream A; id `issue-extime-untested-paths`) An out-of-stock product's rendering, a genuine multi-variant product, and the French tree; also the services sitemap returns a server error, so sitemap coverage is not catalogue coverage there. The collector skips rather than guesses in each case. - **The back office: six mechanisms parked with their columns already in place** (P3; raised 2026-09-04 by rian; id `issue-back-office-parked`) AI-assisted QA (a local model proposes brand merges, draft descriptions and likely inconsistencies; humans confirm in batch); per-source identity mode with a consent record; human data-entry fallback with a likely-stale flag; the merge review queue with recorded merges; verified-field semantics through the single overrides record; the reverification queue with scoring and human-fed re-ranking. The columns land in migrations #1 to #4 so nothing is thrown away; the behaviour waits for the back office after Cannes (plan section 4). - **Per-platform recipes for the six text-fetch collectors** (P3; owner DOCS; raised 2026-09-09 by Stream N; id `issue-per-platform-recipes-for-the-six-text-fetch-collectors`) COLLECTORS.md carries a recipe only for the two rendered sources (Changi, Shilla). Avolta, Shopify, ARI, Extime, Dubai and the two Heinemann collectors are documented by their module docstrings, the posture table and the read_one table. One recipe each in the same shape (how discovery works, what a listing page yields, the skip reasons it reports, its robots posture and crawl delay, the fixtures that pin it). Half a day; the buffer week's WARN-tier doc pass (X4) is the natural home. - **main.tsx imports app.css after the components, so a shared rule beats a component override** (P3; owner C; raised 2026-09-09 by Stream N; id `issue-main-tsx-imports-app-css-after-the-components-so-a-share`) Stream C's 5 Sep handoff: two fixes that night were worked around because app.css is imported after the component stylesheets, so a single-class rule in app.css wins over a component's own override of the same property. Root fix is the import order in main.tsx (app.css first, components after) with a check that nothing visibly changes on the six main pages. - **mammoth's Markdown writer is deprecated upstream** (P3; owner D; raised 2026-09-09 by Stream N; id `issue-mammoth-s-markdown-writer-is-deprecated-upstream`) The Word hand-in reader (_read_docx in the articles import) uses mammoth's Markdown output, which its maintainers have deprecated. Isolated in one function; the swap is to mammoth's HTML output plus the project's own HTML-to-Markdown step, or to keep HTML for Word hand-ins. Nothing breaks today; it breaks on a future mammoth upgrade. - **docs-check should warn when items.json is newer than its generated mirrors** (P3; owner DOCS; raised 2026-09-09 by Stream N; id `issue-docs-check-should-warn-when-items-json-is-newer-than-its`) The two markdown registers are regenerated by every items.py add and resolve, but a hand edit to import/items.json (or a crash between write and export) leaves .logs/issues.md and .logs/decisions-for-rian.md behind with nothing to say so. One WARN-tier line in docs-check.sh comparing mtimes, in the X4 pass. - **Settings still lists the editorial sample key, which gates nothing** (P3; owner C; raised 2026-09-09 by Stream N; id `issue-settings-still-lists-the-editorial-sample-key-which-gate`) CLIENT-SURFACES.md documents it as harmless: the home page's sample editorial block was replaced by the real latest-articles block, so the 'editorial' switch on /settings toggles nothing. Remove the key from FEATURES and the settings page, and drop the sentence from CLIENT-SURFACES.md in the same change. - **docs-check --strict trips CLIENT-SURFACES.md at every checkpoint because import/ is one of its sources** (P3; owner DOCS; raised 2026-09-09 by Stream N; id `issue-docs-check-strict-trips-client-surfaces-md-at-every-chec`) The strict gate compares the commit date of a doc with the newest commit touching each of its named sources. CLIENT-SURFACES.md names import/ (the plan and running-list files the /plan page reads live), and every checkpoint commits import/progress.json and import/items.json, so the doc reads as stale the moment a session records its status, with nothing in the doc to update. Either the gate should ignore data files that are trackers by design (import/*.json, .logs/verification/), or the doc should name main/app/routers/plan.py and items.py as the sources instead of the data directory. Found on the night of 10 Sep, when the closing commit produced the only strict fail. - **Before a second uvicorn worker: a login_attempts table, and a levels memo** (P3; owner R; raised 2026-09-10 by Stream R; id `issue-before-a-second-uvicorn-worker-a-login-attempts-table-an`) The per-address login throttle, the unknown-name throttle and the argon2 semaphore live in the process (routers/auth.py, services/passwords.py). One worker is the launch assumption written into ACCOUNTS.md and the RUNBOOK; a login_attempts table keyed on address and folded name, plus a short-TTL memo over the kit's levels reads, come before a second worker or a second host. Also: the account page offers sign out on this device and a password change (which signs every other device out); a separate sign-out-everywhere button is R2 polish. - **Let's Encrypt cannot validate the zone; production runs on a Cloudflare Origin CA certificate** (P3; owner E; raised 2026-09-10 by Stream E; id `issue-let-s-encrypt-cannot-validate-the-zone-production-runs-o`) Fifteen attempts on 10 Sep failed at Let's Encrypt's secondary validation (networking error looking up TXT and CAA at the zone's nameservers) although the challenge record was published correctly and every public resolver saw it. Caddy serves a 15-year Origin CA certificate instead, which only Cloudflare trusts, so the zone must stay proxied (orange) and Full (strict). If the zone is ever un-proxied, revisit: the DNS module and its token are still configured in deploy/caddy/. See `.logs/runs/production-first-deploy-2026-09-10.log` - **The fetch port's block markers miss two challenge pages served behind HTTP 200 (Incapsula, Radware)** (P3; owner A; raised 2026-09-11 by Stream G; id `issue-the-fetch-port-s-block-markers-miss-two-challenge-pages`) main/app/services/collectors/fetch.py, _looks_blocked: on 11 Sep www.parisaeroport.fr answered an Incapsula frame ('Request unsuccessful. Incapsula incident ID') and www.torontopearson.com a 'Radware Captcha Page' (H1 'We apologize for the inconvenience'), both HTTP 200, and fetch() returned them as pages. Add 'request unsuccessful', 'incapsula', 'captcha' and 'we apologize for the inconvenience' to the markers so every collector treats them as SourceBlocked. The hours collectors judge these on content themselves meanwhile (services/hours/base.py looks_challenged), which is a second copy of a rule that belongs in the port. - **Mount the opening hours provenance as a per-airport row on /collectors** (P3; owner M; raised 2026-09-11 by Stream G; id `issue-mount-the-opening-hours-provenance-as-a-per-airport-row`) The per-airport view of the review area (rian's stated order, third item) is where the hours provenance lands. Stream G built the read and the component; CollectorsPage.tsx is Stream M's file during wave one, so this is the exact mount rather than an edit. Import: import { hoursProvenanceLine } from "../components/AirportHours"; (main/web/src/components/AirportHours.tsx) and, per airport row, fetch GET /api/airports/{iata}/hours (shape {kind: collected|hand|none, text, observed_at, entered_by_username, source_url}; a hidden airport answers 404) then render hoursProvenanceLine(...) or nothing at all when kind is none; the AirportDetail's guide.hours_provenance carries the same fields (kind, observed_at, entered_by_username, source_url, source_host) if the page already holds the detail. Wording rule: a date, never 'verified', never a rate. Per airport it should read: 'Hours collected 11 Sep 2026 from www.heathrow.com' or 'Hours entered by rian 12 Sep 2026' or nothing. - **V2 (the per-airport view) carries the opening hours provenance** (P3; owner R; raised 2026-09-11 by Stream G; id `issue-v2-the-per-airport-view-carries-the-opening-hours-proven`) When Stream R3 builds V2, the per-airport view of the collection page, it shows per airport whether the hours were collected or hand-entered and the date, and nothing at all where neither exists (rian's decision of 11 Sep, AWAY-PLAN.md section 3). The read is GET /api/airports/{iata}/hours and the line is hoursProvenanceLine() in main/web/src/components/AirportHours.tsx; the shape is written in main/docs/COLLECTORS.md under Opening hours. The same issue is filed for Stream M's /collectors mount during wave one; whichever page survives the consolidation carries it. - **DATA-MODEL.md: the airport_hours table's rationale, beside its generated row** (P3; owner DOCS; raised 2026-09-11 by Stream G; id `issue-data-model-md-the-airport-hours-table-s-rationale-beside`) main/docs/DATA-MODEL.md is Stream M's file during wave one, so Stream G left its hand-written part alone; the generated Tables block already lists airport_hours. Paragraph to add under 'Why it is shaped this way': Opening hours are observations like prices: one row per reading (airport_hours), collected from the airport operator's site or entered by hand (source_kind), dated (observed_at), the hand row named to an account (entered_by_id, a who-column), nothing deleted; the reader shows the newest hand row over any collected one, so a human value is never overwritten by a machine and a later collected reading is stored unshown. location_id points at one of the airport's shop rows, the way every airport fact is keyed; text is the one line the page prints and detail the stores behind it (services/hours/store.py, COLLECTORS.md Opening hours). - **Product cards and pages show the brand as one shop spelt it, not the house's preferred name** (P3; owner B; raised 2026-09-11 by Stream M; id `issue-product-cards-and-pages-show-the-brand-as-one-shop-spelt`) catalog_queries.list_products and get_product return products.brand (the spelling the first shop used: 'PACO RABANNE', 'Paco Rabanne', 'Rabanne') while the brand page already resolves the alias to the house. Once a brand alias is confirmed in the merge session (brands.canonical_id, decided_by), every card and product page should show the house's name (brand_row -> canonical -> name) and link to its page; the collected spelling stays on the row as the raw record. Small change in catalog_queries (join brands, follow canonical_id once) and the BrandOut/ProductOut shapes; the line page (the follow-on rian decides) will need the same resolution for product_lines.canonical_id. - **Product markup: a barcode that arrived through a merge is marked, and the JSON-LD should say so or leave it out** (P3; owner B; raised 2026-09-11 by Stream M; id `issue-product-markup-a-barcode-that-arrived-through-a-merge-is`) products.gtin_source is 'merge' when the survivor of a merge gained its barcode from the row folded into it (its own shops never published that barcode); NULL or 'collected' means a shop published it. seo.py writes gtin13 into the product page's JSON-LD; for a merge-sourced barcode either omit gtin13 or keep it only when the merged row's listing still stands at a shop that published it. Stream M's part (the marking, migration c6d7e8f9a0b1) is done; the markup decision is Stream B's. - **Three platforms keep no fragment for most listings, so the Listings view cannot show their tile** (P3; owner A; raised 2026-09-11 by Stream M; id `issue-three-platforms-keep-no-fragment-for-most-listings-so-th`) raw_records exist for 11,098 of 23,771 listings on the 11 Sep copy. Extime keeps a fragment for 200 of 7,036 listings (only the targeted re-reads), Dubai and the three Heinemann-platform shops keep none, so the /collectors Listings view shows an empty left side for them and a rederive cannot re-read what they said. Each collector already builds the RawListing from a fragment; passing it as raw=facts_only(...) at every yield (the way Avolta, Shopify and ARI do) closes the gap. ## Open: watch, parked, later - **A base-colour switch on /settings beside the accent switch, so a lighter header can be judged live** (owner C; raised 2026-09-13 by rian (in chat, 13 Sep); id `issue-a-base-colour-switch-on-settings-beside-the-accent-switc`) Rian is happy with navy for now and will get Adam's and Mark's final view this week; Mark had asked to avoid dark backgrounds. Rather than decide from a description, add a second brand-review switch on /settings: the base colour behind the header and hero. Same mechanism as the accent (a data attribute on the root, per browser, instant, the shipped look for everyone else): candidates declared in tokens.css as overrides of the navy family, at least 'navy (shipped)' and one light option with AA-checked text and label pairs. The server-rendered header mirror must not change; this is a per-browser preview only. Gates: C5 (costly) — C5 is in progress now: Brand pass two: banners designed into the pages, sponsor sizes decided (then Adam gets the sizes) - **Paco Rabanne and Rabanne are two brands in our data, which splits a whole fragrance line** (owner A; raised 2026-09-11 by planning session; id `issue-paco-rabanne-and-rabanne-are-two-brands-in-our-data-whic`) The company renamed itself from Paco Rabanne to Rabanne in 2023 and our shops have not all caught up. Paris says Paco Rabanne; the Shopify shops and Montreal say Rabanne. The fold joins spellings, not rebrands, so we hold two houses and nothing on one side can ever match the other. What it costs on one line: the 100 ml 1 Million Eau de Toilette exists three times, as '1 Million 10cl' at Paris, '1 Million Eau de Toilette 100 ml' at Bogota, Panama and San Salvador, and 'Rabanne 1 Million EDT 100ml' at Montreal. It should be one product compared across five airports; it is three products comparing nothing. Three parts to the fix: an alias row pointing one house at the other, which the brands table already supports; stripping the brand from the front of a product name before keying, so 'Rabanne 1 Million EDT 100ml' keys like the rest; and stripping concentration words from the name once the attribute carries them. Worth sweeping for other rebrands at the same time. A related case sits in the same line: 'Elixir Eau de Parfum Intense 200 ml' and 'Elixir Parfum Intense 200 ml' are the same bottle held apart because two shops named the concentration differently. Gates: A11 (costly) — blocks A11 (Two categories at twenty each, across airports), due 2026-09-15 - **Brand-at-airport pages: a page type the structure proposal does not have yet** (owner B; raised 2026-09-07 by Mark's SEO review; id `issue-brand-at-airport-pages-a-page-type-the-structure-proposa`) Mark wants brand-and-airport pairing pages above some threshold, for two reasons. Commercially, a brand in a pay-to-play arrangement could get more than one general page. For search, a brand with enough products stocked at one airport deserves its own page there, for example Macallan at Heathrow or JFK. Adam agrees. This is a seventh page type, on the same shape as category-at-airport, and it needs a threshold and Adam's commercial rules before it is built. Gates: P6 (costly) — blocks P6 (Delivery walkthrough with Adam), due 2026-09-18 - **Shops and terminals within one airport are not modelled** (owner A; raised 2026-09-07 by Mark's SEO review; id `issue-shops-and-terminals-within-one-airport-are-not-modelled`) Mark: some system may be required to distinguish duty free shops in different terminals at the same airport, and specialty shops need accounting for, citing a particular shop on the JFK terminal map. Adam adds that Singapore Changi has specialty liquor locations on its second floor. Today a location is one airport and a shop is one retailer at that airport, so a terminal or a named specialty shop has nowhere to live. Affects prices that genuinely differ between terminals, and the 'where to buy' line on a product page. Gates: P6 (costly) — blocks P6 (Delivery walkthrough with Adam), due 2026-09-18 - **Pace per collector is something a person adjusts on /collectors, with notes** (owner M; raised 2026-09-13 by rian (in chat, 13 Sep); id `issue-pace-per-collector-is-something-a-person-adjusts-on-coll`) The columns already exist and are honoured: sources.delay_seconds (read by ingest and verify), sources.max_concurrency, sources.notes, and each rendered collector's own floor. Nobody can set them from a page. On the Collectors view, per collector: the pace between requests, the render floor where there is one, and a notes field for what a person learned about that host (when it refused us, at what pace, what the operator said), each change recorded against the account that made it. Rian's stance: crawl continuously rather than fast; the pace is a knob, not a constant. Gates: M6 (costly) — the work it gated has gone ahead under the assumption; settling it now avoids a costlier change later - **Request to the caddie-ui pack: a mention picker in Composer** (owner caddie; raised 2026-09-13 by rian (in chat, 13 Sep); id `issue-request-to-the-caddie-ui-pack-a-mention-picker-in-compos`) Typing @ in a comment box should offer the names the writer may reach, filtered as they type, with arrows and Enter choosing and the handle inserted. The pack's Composer has none, and the Interaction Standard forbids an app re-implementing a pack piece, so this is a pack change: a directory prop on Composer ([{handle, display_name}]) and the picker. DFP's side (T16) supplies the directory through a people route and wires the prop the day the pack ships it. Filed here so rian can carry it into a caddie session; caddie keeps no request file of its own. Gates: T16 (costly) — the work it gated has gone ahead under the assumption; settling it now avoids a costlier change later - **Size nomenclature differs by country: 700ml against 70cl** (owner A; raised 2026-09-07 by Mark's SEO review; id `issue-size-nomenclature-differs-by-country-700ml-against-70cl`) Mark flags that size variants are written differently in different countries and need managing. Migration #3 now stores a size value with its unit and derives millilitres, so the matching side is handled; what is not settled is display. A shop that publishes 70cl should probably still read 700ml on our page for comparability, with the shop's own wording kept in the record. Decide the display rule, then apply it in one place. - **A merge conflict was committed into the running list, and nothing noticed** (owner DOCS; raised 2026-09-11 by planning session; id `issue-a-merge-conflict-was-committed-into-the-running-list-and`) import/items.json was committed on 11 Sep with git conflict markers still in it (commit 0ab8e6c, two sessions appending an item at the same moment). The file stopped being valid JSON, so items.py could neither read nor write and the /plan items tab had nothing to show. Found by hand two days later when a filing failed; resolved by rebuilding both sides and keeping both items. It should not be possible to commit that file broken. Cheapest guard: a line in check.sh that parses import/items.json and import/progress.json and fails on either a parse error or a conflict marker, which also covers the same accident in the plan file. Worth considering an append-safe write path too, since two sessions adding an item at once is now routine. - **Record refusals with the pace at the time, and measure how often prices change per collector, so the crawl cadence is chosen from evidence** (owner Q; raised 2026-09-13 by rian (in chat, 13 Sep); id `issue-record-refusals-with-the-pace-at-the-time-and-measure-ho`) Two ledgers. First, every refusal a collector meets (403, a challenge page, a block mid-run) recorded with the source, the pace it was running at, how many pages it had read, and the time, so the rate a host tolerates can be found rather than guessed; the Singapore retry of 13 Sep is the first entry. Second, per collector, how often prices actually move between reads (the observations already carry every reading and its time), so the cadence per collector follows the shop: a shop whose prices move weekly is read weekly, at whatever pace it tolerates. Both shown on /collectors beside the run history. - **Singapore's pace is thirty seconds: make it the collector's code default as well as the source row** (owner A2; raised 2026-09-13 by planning session; id `issue-singapore-s-pace-is-thirty-seconds-make-it-the-collector`) The 13 Sep retry settled it: iShopChangi refused twice at about ten seconds near page eighteen and accepted twenty pages at thirty. sources.delay_seconds is now 30 on both hosts, which ingest and verify read when no --delay is given. Put the same figure on the collector (Changi.render_floor_seconds = 30.0) so a fresh database or a --delay below it can never run it faster than the shop tolerates, and say so in COLLECTORS.md's pace-per-source note. - **Price charts over time, for products and categories** (owner D; raised 2026-09-07 by Mark's SEO review; id `issue-price-charts-over-time-for-products-and-categories`) Mark has discussed with Adam how useful price history charts would be for selected products and for categories, as part of the site becoming a source of truth for duty free pricing. We already store every observation with its date, so the data exists from now on; this is a display feature, not a collection change. Not for the soft launch. - **Notable price-trend charts on airport pages, chosen algorithmically** (owner D; raised 2026-09-09 by Mark on /structure; id `issue-notable-price-trend-charts-on-airport-pages-chosen-algor`) Mark, 9 Sep: eventually an airport page could carry a 'notable charts' section for goods that have seen interesting price movements, picked by rule rather than by a person. Belongs with the price history work; the observations are already stored dated. - **Fold the discussion workflow into the Interaction Standard and the caddie-ui pack** (owner caddie; raised 2026-09-14 by Stream R2b (14 Sep); id `issue-fold-the-discussion-workflow-into-the-interaction-standa`) The model built on DFP on 14 Sep (.logs/planning/discussion-workflow-2026-09-14.md §2, §3): three states (Open, Resolved with an outcome Done or Later, Archived), one hand-off (an ask: for one person, a note, a turn notification, done by them or a curator), one acknowledgement (Got it on a comment, which completes the person's asks), the closing word as the record, and the counts rule (needs you leads, unread seeded once). For the standard: §4.1 states and outcome, the ask and the acknowledgement as the standard's shapes, §6 the tabs. For the pack: the resolved style without the strike-through, a status line under a resolved card, the ask chip, the Got it thumb, and a Composer mention picker (the earlier request) so DFP's MentionScope can go. See `.logs/planning/discussion-workflow-2026-09-14.md` ## Resolved - **Every launch price is stale until the drinks refresh runs** (P1; owner A; raised 2026-09-03 by Stream A; id `issue-launch-prices-stale`) Newest observation anywhere in the sixteen is 25 Aug; Dubai 21 Aug. The drinks refresh of the sixteen minus the refusing shops is Stream A's first task tonight (A10), after which verify runs its first twenty-page check the next morning. The last-checked date on every price keeps this visible to visitors, which is the point. Gates: A13 (blocking) **RESOLVED 2026-09-05 by planning session:** 5 Sep refresh: every source except Dubai (refuses) has prices dated 5 Sep; deployed in 0.33.0 - **Update header_html() mirror for the mega menu** (P1; owner B; raised 2026-09-05 by Stream C; id `issue-update-header-html-mirror-for-the-mega-menu`) SiteHeader.tsx now wraps the Products item in a group with a toggle, and the nav carries the (closed) browse panel. Row height is unchanged (47.9px measured closed and open; header 126.2px), so the mirror change is markup only, in the same deploy as commit C2. In header_html() replace the first _NAV entry's with exactly:
Products
(the button is empty; its chevron is CSS). The other links are unchanged. After the closing of .site-nav__inner and before , add the closed panel shell so aria-controls resolves: Optional, worth it for crawlers: fill that hidden div with the panel's links server-side (categories via category_counts with count >= 8 to /products?category=..., brands via list_brands sorted by products desc top 12 to their path, airports via list_airports to their path, plus /products and /airports); the SPA never hydrates it, it replaces it, so contents need not match. Classes for the links are in web/src/components/MegaMenu.tsx if you do. Verify: tests/test_seo_body or a token diff of the served nav against headless Chrome's closed-state DOM (scratch check: main/web build, then compare