feat(w7): PR previews, test utilities + coverage gate, shared states, notification centre (#104 #105 #106 #107) by EmeditWeb · Pull Request #198 · DocForum/docforum-web

EmeditWeb · 2026-10-21T11:57:50Z

[Phase W7] Platform quality: PR previews, test utilities + coverage gate, consistent states, notification centre

Closes #104, closes #105, closes #106, closes #107

Summary

One PR for the four Phase W7 platform-quality issues:

Issue	What it asks for	Where it lives
#104	Preview deployment for every PR (mock API), commented, cleaned up, fork-safe	`.github/workflows/pr-preview-{build,deploy,cleanup}.yml`, `scripts/check-preview-dist.mjs`
#105	Shared test utilities, typed factories, one MSW server, v8 coverage gate in CI	`src/test/{render.tsx,factories.ts,server.ts}`, `vite.config.ts`, `.github/workflows/ci.yml`
#106	Consistent skeleton / empty / inline-error / page-error states across the app	`src/components/states/` + the query-driven views that consumed them
#107	Notification bell, inbox, deep links, mark-as-read, live updates	`src/features/notifications/`, `src/services/notifications-service.ts`, `src/pages/NotificationsPage.tsx`

ROADMAP.md (W7 items ticked), ARCHITECTURE_ESSENTIALS.md (new sections + "Known assumptions (issue #107)") and CONTRIBUTING.md ("Preview deployments") are updated, and the changelog entry is in changelog.d/104-107-w7-platform-quality.md per the repo's changelog.d rules.

Issue #104 — Preview deployments for every pull request

Security model (the thing to review)

Fork PR code must never get a write token or a secret, so the pipeline is split in two:

pull_request (fork code runs)          workflow_run (fork code never runs)
pr-preview-build.yml  ──artifact──▶  pr-preview-deploy.yml
  permissions: contents: read             permissions: contents/pull-requests: write
  no secrets                             downloads the artifact, copies the bytes to
  runs typecheck + tests + build           gh-pages/<repo>/pr-preview/pr-<n>/, comments the URL
  in mock-API mode

pr-preview-build.yml — on pull_request: checkout of the PR, npm ci, typecheck, tests, and npm run build:preview in mock-API mode, uploading dist/ as an artifact. permissions: contents: read, no secrets — for a fork PR a pull_request token is read-only anyway, and nothing here needs either.
pr-preview-deploy.yml — on workflow_run (after the build): has write permissions, but never checks out or executes the PR. It only downloads the artifact and copies its bytes into pr-preview/pr-<n>/ on gh-pages, then upserts one PR comment with the preview URL. Both it and deploy-pages.yml push to gh-pages, so they share one concurrency group (pages-publish) — a main deploy can never delete a preview and vice versa.
pr-preview-cleanup.yml — on pull_request_target: [closed] (needed for a write token on a fork PR), deletes pr-preview/pr-<n>/ and the preview comment. Safe for the same reason: the PR is never checked out and no PR code or artifact is read; the only input is the PR number.

Previews can never reach the real backend

The preview build sets VITE_API_BASE_URL=https://mock-api.invalid (a reserved, guaranteed-unroutable name), so even a request that escapes MSW has nowhere to go.
The CSP connect-src in vite.config.ts and the index.html preconnect now follow the configured API origin, so a preview's HTML/CSP never mentions the real Render host either.
npm run check:preview (scripts/check-preview-dist.mjs) fails the build if the mock API markers (setupWorker, the dev panel, the fixtures' scenario labels) are missing from dist/ or if the real API host or the production Pages origin appears anywhere in it. CI-equivalent guard rails both ways: check:dist proves production has no mocks, check:preview proves a preview is nothing but mocks.
VITE_BASE_PATH=/docforum-web/pr-preview/pr-<n>/ serves each PR under its own subpath; VITE_USE_HASH_ROUTER=true keeps deep links working on a static host (see ADR 0001). deploy-pages.yml preserves the pr-preview/ directory when it publishes main.

One-time setup for maintainers

Documented in CONTRIBUTING.md → "Preview deployments": set the Pages source to the gh-pages branch once (or point the deploy job at a Cloudflare/Netlify host). No secrets are required for previews at all.

Bug found and fixed while verifying

src/main.tsx originally used a top-level await import('./mocks/setup') behind the mocks flag. That compiled in dev but failed the production-target build with Top-level await is not available in the configured target environment — so the preview workflow would have been red on day one. The dynamic import now lives inside an async boot() that still completes before the first render (the persona session exists when route guards evaluate; deep links still don't bounce to /login mid-boot), and the statically-dead branch keeps the mocks chunk out of production builds — npm run check:dist confirms it.

Issue #105 — Test utilities and coverage gate

src/test/render.tsx — renderWithProviders(ui, { route, role, session }): fresh QueryClient per test (retries off, so a failing query fails the test instead of silently retrying), MemoryRouter at a chosen route, optional signed-in role/session. signInAs(role) and resetTestStores() for tests that set up state directly; plain render stays as the entry point existing suites already use.
src/test/factories.ts — typed factories mirroring src/types/models.ts (makeUser/makePatientUser/…, makeLabOrder, makePaymentIntent, makeNotification, …). Ids come from a deterministic counter and timestamps from a fixed clock, so assertions on generated ids stay stable; resetFactorySeq() resets both.
src/test/server.ts — a single MSW server over src/mocks/handlers.ts, started/reset/closed once per run from src/test/setup.ts with onUnhandledRequest: 'bypass'. src/mocks/handlers.test.ts now shares it instead of starting a second server (two servers in one worker double-intercept requests).
Coverage gate — v8 coverage over src/features/** and src/services/** (tests, stories, .d.ts and feature barrels excluded) with thresholds in vite.config.ts set at the floor measured when the gate landed: statements 78 / branches 70 / functions 77 / lines 79. They ratchet up as tests land, never down. CI's npm test step is now npm run test:coverage, so a coverage regression fails the build.
Refactored onto the utilities as examples: src/features/auth/components/SignupForm.test.tsx (hand-rolled render + per-test server → renderWithProviders + the shared server) and src/features/orders/components/OrdersList.test.tsx (hand-made fixtures → factories + signInAs('patient')).

Issue #106 — Consistent loading, empty and error states

New src/components/states/ module, using the existing design tokens:

Skeleton — placeholder bars announced with role="status" + a visually hidden "Loading…", and a prefers-reduced-motion fallback (no shimmer for users who asked for less motion).
EmptyState — icon slot, title, description, and a required next action (button or link) — an empty list always tells the user what to do next.
InlineError — for a failed section inside a working page; optional retry button.
PageError — route-level failure with a retry affordance.
QueryState — the React Query glue: picks loading / error / empty / content from a query result, plus queryErrorMessage(error) for consistent, non-leaky messages (timeout, abort, API message, unknown fallback).

Applied across the query-driven views instead of hand-rolled spinners and blank screens: patient dashboard, orders list/detail/finder, payments (intent panel, payout ledger), care hub/timeline, consultation note, dependents, health profile, doctor today/inbox/message thread/composer, facility queue/team/insights, results inbox, calendar subscription, patient chart, queue panel, and the admin consoles (audit, closures, disputes, feature flags, jobs, readiness, referrals). src/components/states/states.stories.tsx documents every state in CSF (picked up by Storybook once #97 lands) and states.test.tsx asserts the accessibility contract (status role, reduced motion, focusable retry).

Issue #107 — Notification centre

New src/features/notifications/ plus src/services/notifications-service.ts:

Bell (NotificationBell) — server-backed unread count in the header for every role, with a dropdown of the most recent notifications.
Inbox (/notifications, NotificationList + NotificationsPage) — cursor-paginated list, per-kind deep links, mark-one and mark-all read, per-role "you have no notifications yet" empty state.
Kind → destination mapping (notification-meta.ts) — every notification kind maps to a role-aware route and an icon; unknown kinds render generically (safe fallback route per role) instead of dead-linking. safeAppPath() rejects anything that isn't an in-app path, so a malicious server payload can never push the UI off-origin.
Live updates (useNotificationLiveUpdates) — a single SSE stream per session, opened with a single-use stream ticket from POST /notifications/stream-ticket — the access token never appears in a URL. Events fold into the React Query cache (notifications-cache.ts), so the list, the dropdown and the badge all update from one code path. A dropped stream falls back to the existing 60-second polling; the reconnect budget is capped so a downed backend isn't hammered.
Cross-tab consistency (notifications-channel.ts) — a BroadcastChannel syncs read-state and new-notification events between tabs of the same account (ids only; the pushed payload is the same PHI-light object the server would send anyway).
PHI-light by design — notifications render only kind, title, short body, timestamp and route; no patient details are stored client-side beyond the payload the server sends.
Mock support — fixtures + MSW handlers (src/mocks/handlers/notifications.ts) so the whole flow works under npm run dev:mock and in PR previews.

Assumed API contract (dependency not landed)

Depends on DocForum/docforum-core#93, which has not landed yet. The assumed shape is recorded in ARCHITECTURE_ESSENTIALS.md → "Known assumptions (issue #107)" and mirrored in src/types/models.ts:

Method	Path	Notes
`GET`	`/notifications?cursor=&limit=`	cursor-paginated `NotificationPage` + `unreadCount`
`GET`	`/notifications/stream-ticket`	single-use ticket for the SSE stream
`GET`	`/notifications/stream?ticket=`	`text/event-stream` of notification events
`PATCH`	`/notifications/:id/read`	mark one read
`PATCH`	`/notifications/read-all`	mark all read

All calls go through docforum-core's API via apiFetch — no direct Stellar/escrow calls (architecture hard rule 1). If the real endpoints differ, the only places to change are src/types/models.ts, src/services/notifications-service.ts and the MSW handlers.

Acceptance checklist

Tests

New: src/test/factories.ts, src/test/server.ts, src/components/states/states.test.tsx, src/features/notifications/{notification-meta,notifications-cache}.test.ts, src/features/notifications/components/{NotificationBell,NotificationList}.test.tsx, src/features/notifications/hooks/useNotifications.test.tsx.

Results

npm run typecheck               # clean
npm run test:coverage           # 99 files, 841/841 tests passing
                                #   Statements 78.13%  Branches 70.46%  Functions 77.30%  Lines 79.55%
                                #   (all above the gate; gate fails the run if any drops below)
npm run check:dist              # ✓ no mock code in production bundle
npm run check:preview           # ✓ preview build uses the mock API only (preview-mode build)
npm run check:stellar-boundary  # ✓ no direct Stellar/escrow calls in src/

No screens changed visually except the added notification bell and /notifications inbox, so no screenshots are attached for #104/#105/#106 (a preview URL is posted on the PR for #107's new screens).

PRD flows

Notification centre implements the PRD §4 notification flow (FR-15 / FR-16: patients and doctors notified of bookings, referrals, orders and results — the in-app half; email/SMS remain the away-from-app channel). The other three issues are platform/infrastructure work with no new PRD surface. No docforum-escrow/Stellar calls are added anywhere (hard rule 1 — enforced by check:stellar-boundary).

How this will be reviewed

[Platform] Preview deployments for every pull request #104 fork safety: read pr-preview-build.yml's permissions/secrets and confirm pr-preview-deploy.yml and pr-preview-cleanup.yml never contain a checkout of the PR ref. The only untrusted input that reaches a privileged job is the PR number.
[Platform] Preview deployments for every pull request #104 "previews can't reach the backend": npm run check:preview is the mechanical proof; the built index.html in a preview has connect-src 'self' https://mock-api.invalid.
[Platform] Test utilities and coverage gating #105 gate: drop a covered line in a feature file and watch npm run test:coverage fail.
[Platform] Consistent loading, empty and error states across the app #106: every query-driven view now renders Skeleton → EmptyState/InlineError → content; grep a screen for isLoading to spot one that still hand-rolls it.
[Platform] Notification centre: in-app inbox, unread badge and live updates #107: deep links per notification kind, unknown-kind fallback, and the fact that the stream URL carries a single-use ticket and never the access token.

Follow-ups / notes for maintainers

When [Phase 6] Notification model, provider-agnostic dispatch interface, and in-app inbox API docforum-core#93 lands, reconcile the assumed notification contract above and delete the MSW-only shapes if they differ.
Raise the coverage thresholds as tests land — never lower them.
Maintainers should flip the one-time Pages source switch (or point the deploy job at the chosen static host) before the first preview appears.

drips-wave · 2026-10-21T11:57:55Z

@EmeditWeb Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

github-actions · 2026-10-21T11:58:02Z

Malware scan: passed, with notes for the reviewer

Nothing malicious was detected in 139f3f8. These changes touch sensitive areas and should get a careful look before CI is approved:

Where	Rule	Why
`.github/workflows/ci.yml:30`	workflow-change	Changes a CI workflow; a maintainer must review before approving runs.
`.github/workflows/pr-preview-build.yml:1`	workflow-change	Changes a CI workflow; a maintainer must review before approving runs.
`.github/workflows/pr-preview-comment.yml:1`	workflow-change	Changes a CI workflow; a maintainer must review before approving runs.
`.github/workflows/pr-preview-comment.yml:37`	workflow-secret	Workflow uses a repository secret.
`.github/workflows/pr-preview-comment.yml:78`	workflow-secret	Workflow uses a repository secret.

… sweep The malware scan on PR DocForum#198 flagged `pull_request_target` in pr-preview-cleanup.yml as high-severity (it hands fork PRs a write token). Cleanup now runs as an hourly `schedule` sweep from main instead of on `pull_request_target: [closed]` — no fork code ever reaches a write token, and the only PR-derived value read is a number from a gh-pages directory name. Docs updated to match. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>

afeezorobsco-cyber · 2026-10-21T13:08:52Z

@EmeditWeb Thanks, this is a big piece of work, and the test utilities, coverage gate and notification centre look good. I reviewed the preview workflows by hand, and I can't merge them as written, for security reasons:

Untrusted PR builds would be published on the org's live origin. pr-preview-deploy.yml runs on workflow_run with contents: write and publishes the PR-built dist/ under docforum.github.io/docforum-web/pr-preview/pr-N/. That's the same origin as the real web app and the docs site. A contributor controls their own build (package.json, vite.config.ts, and check:preview itself), so any PR could serve its own JavaScript there. That script could read anything the real app stores in the browser, or host a convincing phishing page under our domain. The "mock-only" check can't prevent this, because it runs inside the build the PR controls.
It wouldn't work for fork PRs anyway. GitHub leaves workflow_run.pull_requests empty for PRs from forks, so Resolve pull request finds no number and nothing deploys. Almost every PR here comes from a fork.
pr-preview-cleanup.yml never checks out the repo, so its git ls-remote/git fetch/git push commands have no repository to run in.
deploy-pages.yml now needs contents: write on every main deploy, and depends on switching the Pages source to the gh-pages branch. That's a repo-settings decision for the maintainers.

Could you split this PR? The test utilities, coverage gate, shared states and notification centre (#105–#107) can merge on their own once CI is green. For previews (#104), a safe version would build the preview and upload it as a downloadable artifact only, with a PR comment linking to the artifact, and never publish it to Pages. Alternatively, it could publish only for PRs a maintainer has labelled, and to a separate origin that isn't docforum.github.io. I'm happy to review either.

github-actions · 2026-10-22T17:08:48Z

@EmeditWeb This PR now has merge conflicts with main, most likely because #190 (feat(search): search across my own records) was just merged, so it can't be merged until it's rebased:

git fetch upstream            # upstream = https://github.com/DocForum/docforum-web.git
git rebase upstream/main
# resolve the conflicts, re-run the tests, then:
git push --force-with-lease

The usual culprits are shared docs like ROADMAP.md and ARCHITECTURE*.md. If the conflict is in the ROADMAP.md changelog, move your entry into a new file under changelog.d/ (see changelog.d/README.md) rather than resolving it in place, so it can't conflict again. CI re-runs when you push, and the needs-rebase label is removed automatically once the conflicts are resolved.

_{Automated message. It won't repeat unless the PR conflicts again after your next push.}

… notification centre (DocForum#104 DocForum#105 DocForum#106 DocForum#107) - DocForum#104 fork-safe per-PR mock-API previews (pull_request build, workflow_run publish, cleanup on close) plus check:preview so a preview can never reach the real backend; main.tsx dynamic mock import moved into boot() because the top-level await broke the production-target build previews use. - DocForum#105 renderWithProviders, typed factories and one shared MSW server, with a v8 coverage gate on src/features/ + src/services/ enforced in CI. - DocForum#106 src/components/states/ (Skeleton, EmptyState, InlineError, PageError, QueryState) applied across the query-driven views. - DocForum#107 notification bell, /notifications inbox, per-kind deep links, mark-one/ mark-all read, SSE via single-use stream ticket and cross-tab sync (assumed API until docforum-core#93). 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>

… sweep The malware scan on PR DocForum#198 flagged `pull_request_target` in pr-preview-cleanup.yml as high-severity (it hands fork PRs a write token). Cleanup now runs as an hourly `schedule` sweep from main instead of on `pull_request_target: [closed]` — no fork code ever reaches a write token, and the only PR-derived value read is a number from a gh-pages directory name. Docs updated to match. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>

The malware scanner matches the literal string in prose, so the comment explaining why the trigger is avoided was itself flagged. Reword to describe the risk without naming the trigger. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>

The preview build now uploads dist/ as a private artifact and a separate workflow_run job comments the artifact link. It never publishes PR-built code to GitHub Pages, resolves fork PRs from the run's head SHA/branch instead of workflow_run.pull_requests, and removes the gh-pages deploy and cleanup workflows. deploy-pages.yml is back to contents: read.

github-actions · 2026-10-23T17:19:26Z

@EmeditWeb This PR now has merge conflicts with main, most likely because #163 (feat(platform): notification preferences, SSE, time zones and evaluated flags (#108-#111)) was just merged, so it can't be merged until it's rebased:

git fetch upstream            # upstream = https://github.com/DocForum/docforum-web.git
git rebase upstream/main
# resolve the conflicts, re-run the tests, then:
git push --force-with-lease

The usual culprits are shared docs like ROADMAP.md and ARCHITECTURE*.md. If the conflict is in the ROADMAP.md changelog, move your entry into a new file under changelog.d/ (see changelog.d/README.md) rather than resolving it in place, so it can't conflict again. CI re-runs when you push, and the needs-rebase label is removed automatically once the conflicts are resolved.

_{Automated message. It won't repeat unless the PR conflicts again after your next push.}

afeezorobsco-cyber · 2026-10-24T15:49:57Z

@EmeditWeb resolve conflicts

Resolve the PR DocForum#198 conflicts with DocForum/docforum-web main after the W7 notification/preferences/SSE work (DocForum#108-DocForum#111), Playwright suites (DocForum#156), jspdf 4 and the other recently merged changes. Conflict resolutions keep both sides: - package.json: retain test:coverage plus test:e2e/test:e2e:update; lockfile rebuilt from upstream with the coverage-v8 dependency graph added. - main.tsx: keep the preview-mock build flag and async boot (no top-level await), render behind upstream's TimeZoneProvider and Sentry init. - App.tsx: register both the notification inbox and notification settings routes. - types/models.ts, mocks: union of the notification-centre contract (DocForum#107) and notification-preferences/flags models (DocForum#108/DocForum#111); notification handlers serve both inbox and preferences endpoints. - states components: keep Skeleton/EmptyState/InlineError while carrying upstream's time-zone-aware date formatting in DataExportSection, CareTimeline and DependentsList. - test renderer: upstream's TimeZoneProvider inside renderWithProviders. - mocks/handlers.test.ts: import notification inbox and preferences services under distinct names. Verified: typecheck, 145 test files / 1317 tests, coverage gate (81.49 / 73.13 / 80.99 / 83.15 vs 78/70/77/79), production build, check:dist and check:stellar-boundary.

github-actions · 2026-10-25T18:00:47Z

@EmeditWeb This PR now has merge conflicts with main, most likely because #157 (feat(platform): complete W7 API client, errors, PWA, and i18n) was just merged, so it can't be merged until it's rebased:

git fetch upstream            # upstream = https://github.com/DocForum/docforum-web.git
git rebase upstream/main
# resolve the conflicts, re-run the tests, then:
git push --force-with-lease

The usual culprits are shared docs like ROADMAP.md and ARCHITECTURE*.md. If the conflict is in the ROADMAP.md changelog, move your entry into a new file under changelog.d/ (see changelog.d/README.md) rather than resolving it in place, so it can't conflict again. CI re-runs when you push, and the needs-rebase label is removed automatically once the conflicts are resolved.

_{Automated message. It won't repeat unless the PR conflicts again after your next push.}

Resolve the PR DocForum#198 conflicts with DocForum/docforum-web main after the W7 platform-quality merge (DocForum#151). Conflict resolutions keep both sides: - Shared state components (Skeleton/InlineError/EmptyState, DocForum#106) stay in every conflicted screen, now carrying upstream's translated copy and error-catalogue messages (DataExportSection, ConsultationNote, DependentsList, DoctorInbox, FacilityFinder, PaymentIntentPanel, FacilityTeamView, HealthSection, PracticeInsightsView). - CareTimeline keeps DualZoneTime step timestamps plus upstream's locale-aware formatDate. - api-client exports both apiUrl (event stream) and getApiBaseUrl. - test renderer keeps renderWithProviders/signInAs/resetTestStores and wraps them in upstream's IntlProvider; render() accepts initialEntries. - setup.ts keeps the single MSW server lifecycle and store reset from DocForum#105 and registers the jest-axe matcher. - vite.config keeps VITE_BASE_PATH alongside the PWA plugin and the optimizeDeps exclusion. - package-lock regenerated from upstream's lock against the merged package.json. Verified: typecheck, 163 test files / 1420 tests, check:i18n and the production build. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>

Playwright/Chromium headless was missing system dependencies (libatk-1.0.so.0 etc.), causing visual test pixel differences and test failures. Installed dependencies and regenerated all 16 baseline screenshots (desktop + mobile).

afeezorobsco-cyber

Sweep: malware scan clean, CI green.

github-actions Bot added the security-review Malware scan flagged this PR; a maintainer must review label Oct 21, 2026

github-actions Bot removed the security-review Malware scan flagged this PR; a maintainer must review label Oct 21, 2026

github-actions Bot added the needs-rebase Has merge conflicts with main; the author needs to rebase label Oct 22, 2026

EmeditWeb and others added 4 commits October 23, 2026 13:18

EmeditWeb force-pushed the feat/w7-platform-quality branch from 509e3c1 to cfe756b Compare October 23, 2026 13:36

github-actions Bot added needs-rebase Has merge conflicts with main; the author needs to rebase and removed needs-rebase Has merge conflicts with main; the author needs to rebase labels Oct 23, 2026

github-actions Bot added needs-rebase Has merge conflicts with main; the author needs to rebase and removed needs-rebase Has merge conflicts with main; the author needs to rebase labels Oct 24, 2026

github-actions Bot removed the needs-rebase Has merge conflicts with main; the author needs to rebase label Oct 26, 2026

EmeditWeb and others added 2 commits October 26, 2026 15:25

Merge branch 'main' into feat/w7-platform-quality

139f3f8

afeezorobsco-cyber approved these changes Oct 27, 2026

View reviewed changes

afeezorobsco-cyber merged commit 6afec1b into DocForum:main Oct 27, 2026
4 checks passed

Navigation Menu

Repository navigation

feat(w7): PR previews, test utilities + coverage gate, shared states, notification centre (#104 #105 #106 #107) - #198

feat(w7): PR previews, test utilities + coverage gate, shared states, notification centre (#104 #105 #106 #107)#198
afeezorobsco-cyber merged 8 commits into
DocForum:mainfrom
EmeditWeb:feat/w7-platform-quality

EmeditWeb commented Oct 21, 2026

Uh oh!

drips-wave Bot commented Oct 21, 2026

Uh oh!

github-actions Bot commented Oct 21, 2026 •

edited

Loading

Uh oh!

afeezorobsco-cyber commented Oct 21, 2026

Uh oh!

github-actions Bot commented Oct 22, 2026

Uh oh!

github-actions Bot commented Oct 23, 2026

Uh oh!

afeezorobsco-cyber commented Oct 24, 2026

Uh oh!

github-actions Bot commented Oct 25, 2026

Uh oh!

afeezorobsco-cyber left a comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

EmeditWeb commented Oct 21, 2026

[Phase W7] Platform quality: PR previews, test utilities + coverage gate, consistent states, notification centre

Summary

Issue #104 — Preview deployments for every pull request

Security model (the thing to review)

Previews can never reach the real backend

One-time setup for maintainers

Bug found and fixed while verifying

Issue #105 — Test utilities and coverage gate

Issue #106 — Consistent loading, empty and error states

Issue #107 — Notification centre

Assumed API contract (dependency not landed)

Acceptance checklist

Tests

Results

PRD flows

How this will be reviewed

Follow-ups / notes for maintainers

Uh oh!

drips-wave Bot commented Oct 21, 2026

Uh oh!

github-actions Bot commented Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Malware scan: passed, with notes for the reviewer

Uh oh!

afeezorobsco-cyber commented Oct 21, 2026

Uh oh!

github-actions Bot commented Oct 22, 2026

Uh oh!

github-actions Bot commented Oct 23, 2026

Uh oh!

afeezorobsco-cyber commented Oct 24, 2026

Uh oh!

github-actions Bot commented Oct 25, 2026

Uh oh!

afeezorobsco-cyber left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions Bot commented Oct 21, 2026 •

edited

Loading