The company page is the per-stock view of the dashboard. It lives at /#stock/<TICKER> (for example investor.vellamsetti.com/#stock/TSLA). Ongoing work on it is tracked in #137, which stays open as a living work item.

Sources: issues #87, #125, #126, #133, #137, #140 and #141; PRs #131, #134, #139, #142 and #143; and the code on main at d084b67 (Oct 10, 2026, 2:10 PM PT): apps/web/stock-page.js, apps/web/app.js (renderStockPage), apps/web/routes.js.

Status, Oct 10, 2026 (about 2:15 PM PT): the page is live, but it shows no company-collector metrics yet. Every catalog metric is still proposed, and main hides proposed metrics. PR #143, which would show them with a Pending review label, is open and not merged.

From the per-stock vision in #87: give each watchlist stock its own page with the metrics investors actually watch for that company. Many of those aren't in standardized XBRL financials. For Tesla, that means FSD subscriptions, Semi, Robotaxi, Superchargers, energy storage and Optimus. The page also shows IR fundamentals and quarterly-call material. Every value must be source-backed (source URL, document hash, confidence and approval state). Missing quarters show "not reported", never zero, and nothing is shown until Ram approves it.

The company page (/#stock/<T>, any watchlist ticker) is separate from the older research page (/ticker/TSLA, /ticker/SPCX only), which still exists and has the Government contracts and About this data panels.

So there's no visible button on the main dashboard that opens the company page now. PR #139 left it to the owner to decide whether Enter, long-press and the URLs are enough. The ↗ arrow next to a ticker still exists, but it opens the research page (/ticker/<T>), not the company page.

Note: the #137 body still says the page opens from "Open company page" at the top right of the chart panel, and it lists the ticker-bar arrow as an owner observation. Both were overtaken by PR #134 and PR #139.

Signing in is required. The API (GET /stock/{ticker}) returns 401 without a token and 403 for a ticker that isn't in your watchlist.

Heading at 1440px, Industrial Dark, before and after #133 item 1 (PR #134 capture, fixture data, from docs/design-roadmap/issue-133/).

• Heading (stock-heading): TICKER · Company name on the left, then the last price and day change, Updated <Mon D>, and a freshness line (see section 4). Company names come from the payload, or a built-in map (TSLA, SPCX), or else the ticker itself. Based on #125 and PR #131.
• Back to dashboard: a native <a href="/">, keyboard-focusable, with a 44px target. It's pinned in the heading's top-right cell on desktop and at 390px (#133 item 1, PR #134). Back restores the dashboard's previously selected ticker.
• Compact price chart (price-panel-compact) under the heading, using the same price panel as the dashboard.
• Section panels: Operating KPIs, Fundamentals (titled "SEC filings" or "IR fundamentals"), and Quarterly call notes. Inside each section, metric cards sit two per row from 1024px and one per row below that. An odd last card stays on the left (#125, PR #131).
• Phone tabs: below 640px the page shows tabs (Overview, KPIs, Fundamentals, Calls). They use arrow, Home and End keys and the compact --control-height button (PR #139).
• Axes (#133 item 2, PR #134): the x-axis has one Q1–Q4 label per quarter, with the year on its own line below. Narrow widths thin the quarter labels. The y-axis has rounded amount ticks with units ($1.2B, 45%, 400K vehicles).
• No DS-11 line: the provenance/XBRL source line under each chart was removed from the UI (#133 item 3). The serving data is unchanged.
• Theme (PR #139): the company-page panels use the Filings & events panel theme in all six themes: shared panel chrome, IBM Plex Sans, month-and-day dates (Oct 8), and QoQ/YoY shown as a colored dot plus Uptrend / Downtrend / Flat with the ▲/▼ move. PR #139 also themed Government contracts and About this data, but those panels are on the dashboard and research page, not the company page.

Metric card at 1440px, before and after #133 items 2 and 3. Fixture data: the 465,000 deliveries value is not a real figure.

Heading at 390px, Clean Light. These captures are from before the PR #139 panel theming, so fonts and the freshness date format look slightly different now.

Each metric card shows the series (gaps filled as "not reported"), the latest value and period, QoQ/YoY, and, for collector metrics, the source link, published date, confidence and an XBRL reconciled or mismatch mark.

Freshness line states (freshnessBadge):

• Loading company metrics
• Add <T> to your watchlist to see company metrics (403)
• No company-specific metrics discovered (404 or no payload)
• Company metrics could not be loaded. Retry (5xx or network)
• Partial run · previous approved values kept (stale, partial or failed run)
• No approved company metrics (payload but nothing approved; the current state for TSLA)
• IR data approved (when at least one metric is approved)

From #140 items 4–5, implemented in open PR #143, and #137 / #87:

• GAAP chart panels, one per collected metric with a time series (revenue, net income, operating income, R&D, SG&A, EPS, deferred revenue, operating cash flow, cash and investments, and more), with the #125/PR #139 layout and Q1–Q4 axes. Panels come from each ticker's metric registry (catalog), not a hard-coded Tesla list. PR #143 adds chart, KPI, table and text panel kinds.
• CapEx panel (#140 item 5): a quarterly chart for any company with a capex metric, with the latest QoQ and YoY marks, operating cash flow and free cash flow for context, and a revised-period mark where the definition changed (Tesla from 2025Q1). The #140 context gives TSLA 16 quarters through 2026Q1, at $2,493M.
• Unique quarterly-report panels as KPI tiles, tables, status lists or short text cards, with quarter and source. For Tesla:
  • deliveries and production by model
  • active FSD subscriptions (1.48M in the Q2 2026 deck)
  • energy storage deployed (13.7 GWh in Q3 2026)
  • Supercharger stations and connectors
  • Robotaxi metros and status
  • Optimus production lines and milestones
  • Tesla Semi commissioning and production status
  • every factory being deployed, with its products, installed capacity (for example California Model 3/Y >550,000, Shanghai >950,000, Berlin Model Y >375,000, Texas Model Y >250,000) and status
  • AI compute (Cortex 1 >90 MW, Cortex 2 >115 MW)
  • 4680 and LFP cell capacity
  • outlook and product milestones
• SpaceX (SPCX) (#141): segment revenue (Space, Connectivity, AI), segment and total Adjusted EBITDA, total capex, launches, mass to orbit, Starlink subscribers and ARPU, AI nameplate compute, backlog and Starship flights.
• Nvidia (NVDA) (#141): Data Center revenue (Hyperscale vs AI Clouds, Industrial & Enterprise), Edge Computing, Compute & Networking vs Graphics, gross margin, next-quarter revenue and margin outlook, DSO, buybacks and dividends, and the China/export-control note. Nvidia's fiscal year ends in late January.
• Other watchlist tickers: the #141 comment proposes lists for AAPL, AMZN, BYND, EVGO, GOOG, META, MRVL, PLTR and QS (for example AWS, Search/YouTube/Cloud, daily active people, EVgo stalls, Palantir US commercial and government revenue).
• Sustainability (Impact) report and other company reports (#140): sustainability metrics, energy deployment trends and Supercharger network growth. The Impact Report is annual and on tesla.com, which returns 403 to automated requests. It needs an allowed source (a PDF link, SEC exhibit or manual upload), and the collector must not work around the block.
• Fundamentals overlay on the main dashboard fed by the same collected data (#140 item 4).
• From #87 (later phases): Guidance & Outlook, Quarterly Call Notes from licensed transcripts, and XBRL reconciliation flags in the IR fundamentals panel.

flowchart LR
  E[SEC EDGAR<br/>submissions, 8-K EX-99.1 / EX-99.2,<br/>10-Q / 10-K, XBRL companyfacts] --> C[Q2C collect<br/>invdash-q2-company-ir-collect]
  C --> R[(raw/company_ir/TICKER/PERIOD/<br/>docs + manifest, SHA-256)]
  C -- Job Finished --> X[Q2X extract]
  R --> X
  K[catalog/TICKER.json<br/>metric registry] --> X
  X --> CU[(curated/company_metrics/ticker=TICKER/<br/>Parquet)]
  X -- Job Finished --> S[Q2S serve]
  CU --> S
  K --> S
  S --> SV[(serving/stock/TICKER.json)]
  SV --> API[prefs-api GET /stock/TICKER<br/>Cognito, watchlist-scoped]
  API --> P[Company page<br/>stock-page.js / renderStockPage]

1. Collect (Q2C). Runs weekdays on cron(15 7 ? * MON-FRI *), but plan_collection only collects on Mondays (UTC) or inside an earnings window (T-3 to T+5), and on ticker-added. EDGAR is the primary source and uses the InvestorDashboardIR/1.0 (<SEC_USER_AGENT>) identity under 10 requests/second. www.tesla.com and the ir.tesla.com HTML pages aren't fetched (403). Since PR #142, exhibits are found by SEC document type from the filing -index.html or the <TYPE> in the full submission, and both EX-99.1 and EX-99.2 are kept.
2. Extract (Q2X). Parses EX-99.1 tables and, since PR #142, flowing-text KPI rows (Tesla deck, SpaceX release). It reconciles GAAP overlaps against XBRL (0.5% tolerance), differences year-to-date cash-flow items into quarters, and derives the fiscal period from the release text and the fiscal-year end (Nvidia 0131). Rows land in curated/company_metrics/ keyed by (ticker, metric_id, fiscal_period). LLM extraction is off (COMPANY_IR_LLM_SECRET_ID unset).
3. Serve (Q2S). Builds serving/stock/<T>.json. On main it includes approved metrics only. A partial or failed run keeps the previous approved values. Scale-warning flags are now scoped per ticker (PR #142).
4. API and page. GET /stock/<T> reads the serving file. A missing file returns "No company-specific metrics discovered". The page renders what it gets.

More detail: Company Metrics Collector and Data collectors §7.10–7.12.

• Metric registry: services/data-jobs/src/functions/company_ir/catalog/<T>.json. Each entry has metric_id, display name, unit, definition, category, aliases, status (proposed / approved / rejected), approved_by and approved_at. load_catalog merges a generic GAAP catalog into every ticker, so tickers without a file still keep their XBRL rows (PR #142).
• Current state on main: TSLA has 47 entries, SPCX 15 and NVDA 11. All are proposed. Nothing is auto-approved. LLM-only values can never be approved.
• What main shows: approvedMetrics() drops anything proposed or rejected, so the page shows "No approved company metrics", and the Fundamentals section falls back to the Q1 "SEC filings" series.
• Pending review (#140 / PR #143, open): serve and the API would pass proposed metrics through with their status, confidence and source. Approved values come first. Proposed values get a Pending review badge, and an Approved only switch hides them. LLM and rejected rows stay out.

Since PR #159 (Oct 11), an admin can approve or undo a metric from the company page. See 8. Company metric approval. The CLI below still works and is the only way to reject a metric.

services/data-jobs/scripts/approve_metric.py exists on main. It wraps set_catalog_status and validate_catalog. See services/data-jobs/src/functions/company_ir/README.md.

1. Pick the metric from catalog/<T>.json. TSLA ids include total_deliveries, fsd_subscriptions, energy_storage_deployed, supercharger_stations, capex, revenue_gaap and operating_income. Approve only metrics you've checked against the source. No metric may be approved without Ram's explicit decision.
2. On a branch, from the repo root:

   python services/data-jobs/scripts/approve_metric.py TSLA total_deliveries --by ram
   # reject instead:
   python services/data-jobs/scripts/approve_metric.py TSLA total_deliveries --by ram --status rejected
   # back to proposed:
   python services/data-jobs/scripts/approve_metric.py TSLA total_deliveries --status proposed

   --by is required to approve. approved_at defaults to now (UTC), or pass --at <ISO timestamp>. Rejecting clears the reviewer fields. The script fails if the ticker has no catalog file.
3. Or edit the JSON by hand: set status to approved and fill approved_by and approved_at.
4. Open a PR. CI fails if an approved entry has no approved_by. Merging to main deploys the catalog with the job image.
5. The next Q2S serve writes the metric into serving/stock/<T>.json, and it appears on /#stock/<T>. Serve runs after extract, after collect.
6. For a ticker without a catalog, run python services/data-jobs/scripts/propose_catalog.py <T> --fixtures <exhibit.html> --write, review the proposed file, and open a PR. That script never approves and doesn't open the PR itself.

Sources: PR #159 (merged Oct 11, 11:41 AM PT), issues #147, #161 and #166, and the #166 UI PR PR #167. All code references are to main at a39b5a7 (Oct 11, 2026, 4:40 PM PT), which already includes PR #167.

Status, Oct 11, 2026 (about 4:45 PM PT): the in-app approval workflow from PR #159 is deployed (Deploy production #202, 11:45 AM PT). Clicking Approve on the live site has not been changing the state (#166 item 5). The fix is in PR #167. It was expected to stay open for owner review, but it was merged at 4:40 PM PT and is no longer open. Its CI run was still in progress at the time of writing. Production deploys only after CI passes on main, so the fix is not live yet. See 8.7 Known issue.

The company-metrics collector (Q2C collect → Q2X extract → Q2S serve, see section 5) only proposes metrics. A collected metric stays proposed (shown as Pending review) until a person approves it. Approval is the human gate between "the collector found this number" and "the dashboard treats it as a fact":

• Approved metrics are listed as approved in the Company metrics panel, and they can be added to the main dashboard's Fundamentals chart overlay group.
• Pending review metrics still draw as charts on the company page, but they never show up in the main dashboard Fundamentals overlay.
• A later collect can add new proposed metrics. It never clears an approval (see 8.6).

Before PR #159, approving meant editing catalog/<T>.json in a PR (the CLI in section 7). Now an admin can approve from the company page.

• Undo sets an approved metric back to proposed and clears approved_by and approved_at.
• Approval is per metric and per ticker (metric_id in catalog/<T>.json), not per quarter.
• LLM-only values can never be approved (catalog validation, section 5).

• Only members of the Cognito group admin in user pool us-west-1_6ZwMxHaH2. Terraform creates the group empty (site_auth/main.tf:70–78, aws_cognito_user_group.admin). Nobody is added in Terraform.
• The public demo account [email protected] is always refused, even if it's added to the group. This is checked both in the browser (canApproveMetrics) and in the API (_is_demo_account). Don't add it.
• Everyone else sees the status (Pending review / Approved) but no buttons. If they call the API directly, they get 403.

Add the owner's account to the admin group (one time, with AWS credentials that can manage the pool):

aws cognito-idp admin-add-user-to-group \
  --region us-west-1 \
  --user-pool-id us-west-1_6ZwMxHaH2 \
  --username <your-email> \
  --group-name admin

# check it
aws cognito-idp admin-list-groups-for-user \
  --region us-west-1 \
  --user-pool-id us-west-1_6ZwMxHaH2 \
  --username <your-email>

Use your own sign-in email (or the Cognito username), not the demo account. Then sign out and sign in again. Group membership is copied into the access token's cognito:groups claim only when a token is issued, so a session that started before you were added won't show Approve.

Company page /#stock/<TICKER>, from top to bottom (app.js:3676–3687):

1. Header (company name and Back to dashboard)
2. Compact price chart
3. Show pending review / Approved only toggle, then Operating KPIs
4. Fundamentals (or SEC filings)
5. Company metrics: the list with Approve and Undo (#161 item 1, PRs #160 and #162)
6. Quarterly call notes (last)

On a phone (below 640px) the Company metrics panel is in the Overview tab, and the toggle is at the top of the KPIs tab.

Company metrics panel

• Approved rows come first, each with an Approved label. Under a Pending review heading come the proposed rows, each with a Pending review badge. The row text shows the latest value and quarter (for example Q3 2026), with the period-end date on hover (#166 item 8).
• An admin sees Approve on pending rows and Undo on approved rows. While a save is running, every button reads Saving and is disabled. Rows marked unavailable get no button.
• Non-admins see only the labels.
• If the save fails, a red message (role="alert") appears at the top of this panel and stays there (#166 item 5, PR #167).

Show pending review / Approved only (above Operating KPIs)

• Show pending review (default): every metric panel on the page shows approved and pending-review metrics (Operating KPIs, Fundamentals, guidance, CapEx, and the Company metrics list).
• Approved only: those panels and the list show approved metrics only. A section that ends up empty shows the themed empty state.
• The selected button is highlighted (aria-pressed="true"). The choice is saved in this browser only (localStorage), not in your account preferences.
• Chart cards don't carry a Pending review badge or an approved/proposed pill (#147 item 5). The list is where status is shown.

Main dashboard Fundamentals overlay

• The Fundamentals group in the main chart's overlay picker lists approved metrics only (#147 item 6). The old <id>_pending "Pending review" chips are gone.
• Approving a metric adds FUNDAMENTAL:<metric_id> to that group without waiting for a collect. Undo removes it.
• A saved overlay that still points at a pending id is dropped quietly (on the chart and when preferences are read or saved). Saving still returns 200.

Screenshots: docs/ has no screenshots of the approval UI yet. The PR #159 and PR #167 captures are attached to those PRs as agent artifacts, not committed. The metric-card screenshot in section 3 shows the card style.

flowchart TD
  U[Admin clicks Approve / Undo<br/>Company metrics panel] --> H[submitMetricReview<br/>apps/web/app.js]
  H -->|"PUT /stock/T/metrics/ID<br/>Authorization: Bearer access token<br/>body: status approved or proposed"| G[API Gateway HTTP API<br/>invdash-site-api<br/>JWT authorizer: Cognito]
  G -->|AWS_PROXY 2.0| L[prefs_api Lambda<br/>invdash-prefs-api]
  L --> A{"_claims_for_review + _is_metric_admin<br/>cognito:groups contains admin,<br/>not the demo account"}
  A -- no --> F[403 Only an admin can change<br/>metric review status]
  A -- yes --> W{"ticker in your watchlist?<br/>metric in serving/stock/T.json?"}
  W -- no --> E[403 / 404]
  W -- yes --> C[(S3 lake: catalog/T.json<br/>status, approved_by, approved_at)]
  C --> S[(S3 lake: serving/stock/T.json<br/>+ T.json.gz, no-store)]
  S --> R[200: public stock document]
  R --> UI[session.stockPage = response<br/>renderDashboard: row shows Approved,<br/>Fundamentals overlay gains the metric]
  subgraph Next collect
    Q2C[Q2C collect] --> Q2X[Q2X extract<br/>review_catalog] --> Q2S[Q2S serve<br/>review_catalog, build_serving]
  end
  C -. read, approval kept .-> Q2X
  C -. read, approval kept .-> Q2S
  Q2S -->|rewrites JSON + .gz| S

1. Button. submitMetricReview(metricId, "approved" | "proposed") sends the PUT with the Cognito access token.
2. API Gateway. Route PUT /stock/{ticker}/metrics/{metric_id} on the HTTP API, behind the Cognito JWT authorizer. A missing or invalid token gets 401 before the Lambda runs.
3. prefs_api admin check. Reads cognito:groups and refuses non-admins and the demo account (403).
4. Catalog write. Read-modify-write of the lake review record catalog/<T>.json: status, approved_by (your email) and approved_at (UTC, ISO 8601).
5. Serving update. The same metric is patched in serving/stock/<T>.json (and its .gz copy), so GET /stock/<T> reflects it right away.
6. UI refresh. The 200 body is the patched company document. The page stores it and redraws, without a separate GET.
7. Collect / extract / serve. Each job reads the lake catalog with review_catalog, so a lake approved (or an Undo back to proposed) wins over the packaged catalog in the job image. preserve_approved_status and merge_proposals never downgrade an approved entry. Serve rewrites the JSON and the .gz together.

UI state after the response: not optimistic. On click, submitMetricReview sets session.metricSave = true and redraws, so the buttons show Saving and are disabled. That flag also blocks a second click. It then awaits apiPut. On 200 it replaces session.stockPage[ticker] with the response body (the server's patched, filtered document) and redraws, so the row moves to Approved and the dashboard overlay group is rebuilt from the same document. There is no follow-up GET; a page reload reads the patched serving file. On error it keeps the old document and puts the error text in session.metricReviewError, which renderCompanyMetrics draws as a role="alert" .metric-review-toast that stays across redraws. If the browser decides you're not an admin, the handler shows "Only an admin can change metric review status." and doesn't call the API.

PUT {apiBaseUrl}/stock/{ticker}/metrics/{metric_id}
Authorization: Bearer <Cognito access token>      (an ID token is also accepted by the authorizer)
Content-Type: application/json

{"status": "approved"}     or     {"status": "proposed"}   (Undo)

• ticker: [A-Za-z][A-Za-z0-9.-]{0,9}, upper-cased by the server. metric_id: ^[A-Za-z][A-Za-z0-9_]{0,64}$ (METRIC_ID_RE, prefs_api.py:62).
• Router: prefs_api.py:975–983. Handler: _review_metric prefs_api.py:891–917.

Every response carries Cache-Control: no-store. 5xx errors are logged as one JSON line {"event":"prefs_api_error","route":"PUT /stock/{ticker}/metrics/{metric_id}","method":"PUT","error_class":…,"code":…} with no body or token (prefs_api.py:534–542, handler prefs_api.py:1025–1044). 4xx responses are not logged by the Lambda.

1. Admin group and demo account. ADMIN_GROUP (env METRIC_ADMIN_GROUP, default admin) and DEMO_ACCOUNT (prefs_api.py:63–65).
   • _claims_for_review (prefs_api.py:708–732) starts from the authorizer claims (_jwt_claims, prefs_api.py:664–672). The HTTP API JWT authorizer passes claims as strings and drops array claims, so cognito:groups can be missing. In that case it decodes the bearer token's payload (_bearer_claims / _unsigned_jwt_payload, prefs_api.py:685–705; the signature was already checked by API Gateway). It uses that token's cognito:groups (and email/username if missing) only if its sub equals the verified sub and token_use is access or id.
   • _claim_groups (prefs_api.py:735–746) accepts a list or string forms such as admin, [admin], [admin users].
   • _is_demo_account / _is_metric_admin (prefs_api.py:758–766): the demo email in email, username or cognito:username always fails; otherwise admin must be in the groups.
   • _reviewer (prefs_api.py:769–774) picks the value written to approved_by: your email/username (never the demo account), else sub.
2. Validation in _review_metric: admin → watchlist (get_prefs) → JSON object body → status in {approved, proposed} → metric present in the current serving document.
3. Catalog read-modify-write. _read_json_object("catalog/<T>.json") (prefs_api.py:781–793). If it's missing it starts from {"ticker", "catalog_version": 1, "metrics": []}. _set_catalog_metric (prefs_api.py:823–841) sets status and, for approved, approved_by and approved_at (datetime.now(UTC), seconds); for proposed it clears both. The lake catalog/<T>.json is the review record. The metric definitions stay in the packaged catalog in the job image (catalog_object_key docstring).
4. Serving patch. _patch_serving_metric (prefs_api.py:862–888) sets approved, approval_state, status, approved_by, approved_at and provenance.approval_state on that metric, re-sorts approved first, and recomputes freshness_label when run_status is ok.
5. Writes. _write_json_object (prefs_api.py:796–820) writes catalog/<T>.json, then serving/stock/<T>.json and, with gzip_sibling=True, serving/stock/<T>.json.gz (gzip.compress, same level, mtime=0). All with CacheControl: no-store (#166 item 5). GET /stock/<T> reads the JSON (prefs_api.py:984–993); the .gz is kept in step so no reader of the sibling gets the old pending document.
6. Concurrency. There is no ETag / If-Match / conditional put on these objects. Two simultaneous reviews of the same ticker are last-writer-wins for the whole catalog/<T>.json and serving file. The only guard is the browser's one-save-at-a-time flag. The catalog is written before the serving file, so if the second write fails, the approval is still recorded and the next serve publishes it.

No new IAM role. The writes use the existing prefs API Lambda role. The jobs' own permissions are separate: extract and serve read catalog/; serve writes serving/stock/.

• catalog_object_key(ticker) → catalog/<T>.json (company_ir.py:421–423); _read_lake_catalog (company_ir.py:472–479).
• review_catalog(packaged, lake) (company_ir.py:446–469): the lake record is the live status, including an Undo back to proposed. It ends with preserve_approved_status.
• preserve_approved_status(existing, incoming) (company_ir.py:426–443): any metric approved in existing stays approved with the same approved_by / approved_at.
• merge_proposals(catalog, proposals) (company_ir.py:2286–2302): adds unknown labels as proposed and never changes a status someone set.
• Called in run_extract (company_ir.py:3862, company_ir.py:3906) and run_serve (company_ir.py:3962). build_serving (company_ir.py:2068) then publishes approved and proposed metrics.
• serve_handler (company_ir.py:4078–4097) writes with write_json_and_gzip(..., cache_seconds=0), so the JSON and .gz are replaced together.
• The repo CLI path is unchanged: set_catalog_status (company_ir.py:401–418) and validate_catalog (an approved entry needs approved_by).

Run: node --test apps/web/*.test.js; cd services/data-jobs && pytest -q.

Symptom (#166 item 5): on the live company page, an admin clicks Approve, the row stays on Pending review, and no error is shown.

Fix: PR #167, item 5 of #166. It was meant to stay open for owner review, but it was merged Oct 11, 4:40 PM PT (a39b5a7). Its deploy runs only after CI passes on main. Until that deploy finishes, the live site still has the bug.

Root cause (from PR #167):

1. The admin check missed the group. The page decides to show Approve by decoding the access token's cognito:groups array. But the API Gateway HTTP API JWT authorizer passes claims to the Lambda as strings and drops array claims. The old _is_metric_admin read only requestContext.authorizer.jwt.claims, so a real admin had no groups and got 403 "Only an admin can change metric review status". Fix: _claims_for_review reads cognito:groups from the same bearer token when the authorizer omitted it, only if sub matches and token_use is access/id. The demo account is still refused.
2. The failure was invisible. Errors went through notify(), a line at the top of the page, which the next renderStockPage wiped. Fix: the error is drawn inside the Company metrics panel (role="alert") and kept across redraws.
3. Stale gzip copy. The write patched serving/stock/<T>.json but not serving/stock/<T>.json.gz, and set no cache header. Fix: both are written with Cache-Control: no-store, and Q2S serve rewrites both (cache_seconds=0).
4. CORS allow_headers gained accept, matching what the page sends.

The route, Lambda permission and IAM write permission were already correct after PR #159. PR #167 notes that its environment had no AWS credentials, so the live API Gateway stage wasn't inspected.

prefs-api logs (region us-west-1):

# Lambda errors for the review route (5xx only; 4xx aren't logged)
aws logs tail /aws/lambda/invdash-prefs-api --region us-west-1 --since 1h \
  --filter-pattern '{ $.event = "prefs_api_error" }'

# API Gateway access log: one line per request, with route and status (shows 401/403/404 too)
aws logs tail /aws/apigateway/invdash-site-api --region us-west-1 --since 1h \
  --filter-pattern '{ $.route = "PUT /stock/{ticker}/metrics/{metric_id}" }'

# What the lake says now
aws s3 cp s3://<lake-bucket>/catalog/TSLA.json - | jq '.metrics[] | select(.status=="approved")'

• #147: the original request: move the Company metrics panel to the company page, approval workflow, period-synced panels, no badges on charts, approved-only dashboard overlay (closed by PR #159)
• PR #159: the approval workflow, PUT /stock/{ticker}/metrics/{metric_id}, admin group, audit fields, serving patch, collector preservation (merged Oct 11, 11:41 AM PT)
• #161, PRs #160, #162, #163, #164: Company metrics panel above Call notes, header, toggle spacing, ticker-bar arrow
• #166 / PR #167: header and panel spacing, toggles filter panels, Approve fix (item 5), readable dates (merged Oct 11, 4:40 PM PT)
• #126, #137, #140, #141, #145: earlier approval and Pending review work
• Company Metrics Collector: the Q2C/Q2X/Q2S jobs

• Company metric approval: in-app Approve/Undo, admin group, API, troubleshooting
• Company Metrics Collector: Q2C/Q2X/Q2S jobs, schedule, run history
• Data collectors: lake layout, §7.10–7.12 company-metrics history, open items
• Dashboard features, Themes