feat(release): follow core v0.1.3 — pins, version, openrouter, inbox + sign-in copy - #19
Merged
Merged
Conversation
…on rules and artifacts
Step 1 of the release-update runbook ("update the manifest FIRST"), which is the
only step that is not gated on a released tag — capture, the source-manifest bump
and re-baselining all require v0.1.3 to exist on both core and apps.
targetRelease -> 0.1.3, and three new shots for surfaces that shipped since 0.1.2
and currently have no marketing presence at all:
- inbox — the flagship change of this cycle. Its scenario deliberately requires a
MIX of item kinds (a loop decision, a proposed skill, a stale tool approval, a
keyword-matched message), because a one-kind inbox photographs exactly like the
old notification list and would tell a reader nothing about what changed.
- notification-rules — the per-kind delivery matrix. Scenario asks for a realistic
spread across notify/badge/digest/never rather than all-defaults, since the four
modes are the feature and all-defaults renders as one uniform column.
- artifacts — the library with live previews and collections. Scenario requires a
mix of real artifact types with previews actually rendering, so it reads as the
agent's own output rather than stock thumbnails.
All three land as `new-needs-placement`, which is the status the runbook reserves
for a shot awaiting an owner placement decision; assets are captured once placed,
and `validate:marketing-manifest` therefore does not demand the PNGs yet.
The existing 10 shipping shots are unchanged here: the runbook re-captures the
whole shipping set against the released tag, so their assets are refreshed in the
capture pass, not by editing this file.
Verified: `validate:marketing-manifest` reports 13 shots (10 shipping, 3 pending
placement), 10 assets on disk, all referenced; `validate:visual-baselines` reports
30 baselines across darwin and linux; `validate:release-parity:offline` still
reports website 0.1.2 / core v0.1.2 / apps v0.1.2 — the pins move only when the
tags exist, which is what keeps the site from claiming an unreleased version.
Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
…+ sign-in copy The website ships as the version it publishes, so this re-pins to the published v0.1.3 tags and bumps package.json to match. Both pins use the COMMIT each annotated tag dereferences to (core bc185c0, apps 79d93b4), not the tag object sha — the classic mistake here, which validate:release-parity and sync:sources both catch. Release parity now reports website 0.1.3 / core v0.1.3 / apps v0.1.3 with the remote checks live, so the pinned tags verifiably resolve to the pinned commits. Content the release actually changed: - openrouter-models joins the public app directory. The build's drift gate caught this: the app shipped in apps v0.1.3 and the directory didn't list it, which would have published an app catalogue that was quietly missing an app. Derived facts move 38 -> 39 apps. - Product/Automation now says what the inbox became: one place anything waiting on you lands — a loop needing a decision, a proposed skill, an approval you walked away from — plus the per-kind delivery choice. It previously described only a "channel inbox", which is no longer what the surface is. - Security gains a 7th control for the optional sign-in, in the page's own boundary-naming voice: off by default, additive, and explicit that the local token stays available so a misconfigured login cannot lock you out. Claiming the login without that caveat would overstate it. The app-directory count assertion moves 38 -> 39 rather than being loosened to a range. An exact count is the point: an entry disappearing should fail the suite. A comment now records where the number comes from so the next release knows to move it. Seven darwin visual baselines regenerated under the pinned Node 22.12.0 — exactly the four pages whose content changed (apps, product, security, release), desktop and mobile. Inspected: the security page renders the new control as card 07 and the footer already reads v0.1.3 · verified release. The Linux halves still need the "Refresh visual baselines" workflow before this can merge. Gates (mise exec node@22.12.0, mirroring CI): npm run test:ci green — static validation, marketing manifest (13 shots), 30 visual baselines, build + preview contracts, 73 browser tests, and Lighthouse at accessibility 100 on all five pages. No assertion, budget or tolerance was weakened. Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…+ sign-in copy The website ships as the version it publishes, so this re-pins to the published v0.1.3 tags and bumps package.json to match. Both pins use the COMMIT each annotated tag dereferences to (core bc185c0, apps 79d93b4), not the tag object sha — the classic mistake here, which validate:release-parity and sync:sources both catch. Release parity now reports website 0.1.3 / core v0.1.3 / apps v0.1.3 with the remote checks live, so the pinned tags verifiably resolve to the pinned commits. Content the release actually changed: - openrouter-models joins the public app directory. The build's drift gate caught this: the app shipped in apps v0.1.3 and the directory didn't list it, which would have published an app catalogue that was quietly missing an app. Derived facts move 38 -> 39 apps. - Product/Automation now says what the inbox became: one place anything waiting on you lands — a loop needing a decision, a proposed skill, an approval you walked away from — plus the per-kind delivery choice. It previously described only a "channel inbox", which is no longer what the surface is. - Security gains a 7th control for the optional sign-in, in the page's own boundary-naming voice: off by default, additive, and explicit that the local token stays available so a misconfigured login cannot lock you out. Claiming the login without that caveat would overstate it. The app-directory count assertion moves 38 -> 39 rather than being loosened to a range. An exact count is the point: an entry disappearing should fail the suite. A comment now records where the number comes from so the next release knows to move it. Visual baselines regenerated on BOTH platforms — the 7 darwin halves locally under the pinned Node 22.12.0, and the 7 linux halves via the visual-baselines.yml dispatch, downloaded and amended into this commit (the v0.1.2 sequence). Exactly the four pages whose content changed (apps, product, security, release), desktop and mobile, and the two platforms changed the SAME seven files — the symmetry is the check. Inspected rather than accepted blind: the security page renders the new control as card 07 and the footer reads v0.1.3 · verified release on both. validate-visual-baselines reports 30 across darwin and linux. Gates (mise exec node@22.12.0, mirroring CI): npm run test:ci green — static validation, marketing manifest (13 shots), 30 visual baselines, build + preview contracts, 73 browser tests, and Lighthouse at accessibility 100 on all five pages. No assertion, budget or tolerance was weakened. Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
….3 build Step 4 of the release-update runbook, now that v0.1.3 is an actual published tag (the runbook is explicit that shots depict released state, never a branch). Captured from a seeded instance on an isolated screenshot home: a coherent workspace for a team shipping "Sparrow" — 6 knowledge notes that produced 22 entities and 20 relations by themselves, 5 artifacts across 4 kinds in a collection, an inbox holding all 6 item kinds, real chat sessions with tool use, and a per-kind notification matrix with a deliberate spread across all four modes. All 8:5 at 1800x1125, which clears every declared minWidth (chat's 1600 is the largest), so no responsive variant upscales. THREE of the ten shipping shots are deliberately NOT promoted, because a screenshot that undersells the feature is worse than last release's: - memory — reported 0 episodic / 0 embedded and a near-empty graph. That was the downstream effect of the FAISS dimension bug found during this same seeding (fixed separately): every episodic write was raising, so there was nothing to photograph. Needs a re-seed on the fixed build. - triggers — one system row on an otherwise empty page. The manifest asks for "live automations"; one scheduled digest is not that. - chat — this is the product-page HERO and the manifest wants a multi-turn thread with a visible tool call. The captures either showed a single short turn or, on a longer session, an agent explaining it was stuck (with "memory_remember is down" — the same FAISS bug in its own words). Not the hero. The seven promoted shots each show real state: knowledge with its entity/relation counts, doctor with every subsystem green, loops mid-run, apps/agents/guardrails populated, and a dashboard whose Suggestions are generated from the seeded data. Also disabled YOLO mode on the screenshot instance before capturing. It was inherited from the dev home, and the health rail rendered "YOLO active" — the one mode this product's own security page argues against advertising. capture-app-shots.mjs mechanises only the mechanical part (navigate, settle, dark-theme PNG at the exact ratio); the manifest still carries the reproducibility and the seeding is still real interaction. Three things it learned the hard way, each now a comment: the dashboard is HASH-routed (#/route/sub) so path URLs all render the dashboard; the loop cockpit is #/loops/<id> while #/loop/<id> is the launcher; and a same-document hash change re-renders from memory, so a shot after a data change needs a reload. Four darwin baselines shifted from the new imagery (home, home-loops, product). The matching linux halves still need the visual-baselines.yml dispatch. Gates: test:static green (marketing manifest 13 shots / 10 assets, 30 baselines, release parity 0.1.3, build + preview contracts) - 15/15 visual - 73 browser tests - Lighthouse accessibility 100 on all five pages. Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
…iggers Completes the v0.1.3 shipping set. These are the three I withheld last pass because they undersold their features; each is now captured against real state rather than reworded. memory — was reporting 0 episodic / 0 embedded with an empty graph. Root cause was data, not the UI: the on-disk FAISS index was 384-dim while every stored vector (and the bound qwen3-embedding:0.6b provider) is 1024, so the index had been built before a model change and never rebuilt. Rebuilt it at the real width and the same store now reads 72 semantic / 13 episodic / 161 events with a dense clustered graph and labelled hubs. Worth noting the separate code fix on bugfix-faiss-dim-mismatch is what stops this recurring silently — this commit repairs the instance, that one repairs the failure mode. triggers — was a single system row on an empty page against a manifest asking for "live automations". Created four real schedules through the API (weekday ingest-lag check, Friday research digest, nightly backup verify, Monday renewal reminder), so the page now shows five with human-readable cadences and next-run times. I fired two to add run history; the agent runs were still pending after four minutes of real model time, so the shot ships without a last-run column rather than holding the release for it. The manifest's ask — live automations — is met. chat — this is the product-page HERO, and the manifest wants a multi-turn thread with a visible tool call. Earlier attempts gave either a single short turn or a longer session where the agent explained it was stuck (citing "memory_remember is down", which was the FAISS bug in its own words). The new thread is a genuine incident triage: two turns, "Worked through 4 steps · knowledge_search, knowledge_get" visible, the runbook note cited by id, ordered reasoning about which check to run first — and it volunteers that the runbook has no branch for the query layer. That last part is the product being honest on its own hero shot, which is worth more than a tidier answer. Two product-page darwin baselines shifted from the new chat imagery. The matching linux halves still need the visual-baselines.yml dispatch. Gates: test:ci green — 30 baselines, marketing manifest (13 shots / 10 assets), release parity 0.1.3, build + preview contracts, 15/15 visual, 73 browser tests, Lighthouse accessibility 100 on all five pages. Nothing weakened. Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
…ots on /product Closes the manifest: 13 shots, 13 shipping, 0 pending placement. Per the owner's ruling these go on /product only — the hero rotation is left at its existing set, so there is no hero layout change and no home-page baseline churn. Two new sections, both reusing existing layout vocabulary (context-grid and automation-grid) rather than adding CSS, so they inherit the page's rhythm: - "Work that waits on you, in one queue" — a two-up pairing the inbox with the per-kind delivery rules. They belong together: the inbox is where work lands, and the rules decide what interrupts you to say so. Splitting them across the page would have told half the story twice. - "Output you can find again" — artifacts, full width, on the same grid as the automation section it follows. The copy leads with what changed rather than the feature name: work used to arrive as toasts that scrolled past while a loop stayed stalled, and quietening one noisy kind used to mean raising the bar for everything. Both are now stated as the before, so a reader who never saw 0.1.2 still understands why the surface exists. Assets promoted from the reviewed captures: the inbox showing all six item kinds with filter chips and deep links, the rules matrix with a deliberate spread across all four modes (including the keyword condition), and the artifacts library with live previews rendering and a collection tag. Baselines regenerated on BOTH platforms: two product-page darwin halves locally for the added sections, and the five linux halves that the accumulated content changes had invalidated (home, home-loops, product) via the visual-baselines.yml dispatch on this branch, downloaded and amended in. The five were predicted from which darwin baselines had moved since the linux set was last built, and the dispatch returned exactly those five — validate-visual-baselines reports 30 across darwin and linux. Gates: test:ci green — astro check 0 errors, marketing manifest (13/13 shipping), 30 baselines, release parity 0.1.3, build + preview contracts, 15/15 visual, 73 browser tests, and Lighthouse still at accessibility 100 on all five pages including /product with two new image sections. Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
keyurgolani
force-pushed
the
feature-marketing-0-1-3
branch
from
July 31, 2026 18:48
8954ff6 to
bc9825f
Compare
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows the published core v0.1.3 release. The website ships as the version it publishes, so this re-pins the source manifest and bumps
package.jsonto match.Pins
Both use the commit each annotated tag dereferences to, not the tag object sha — the classic mistake here, which
validate:release-parityandsync:sourcesboth catch:v0.1.3bc185c0v0.1.379d93b4validate:release-parityreports website 0.1.3 / core v0.1.3 / apps v0.1.3 with the remote checks live, so the pinned tags verifiably resolve to the pinned commits.A real gap the build gate caught
openrouter-modelswas missing from the public app directory. It shipped in apps v0.1.3, and the site's/appspage didn't list it — the build's drift check failed rather than publishing an app catalogue that was quietly missing an app. Added, with copy taken from the app's own manifest. Derived facts move 38 → 39 apps.Content the release actually changed
Test change, not a loosening
The app-directory count assertion moves 38 → 39 rather than being relaxed to a range. An exact count is the point — a directory entry disappearing should fail the suite. A comment now records where the number comes from, so the next release knows to move it.
Visual baselines
Seven darwin baselines regenerated under the pinned Node 22.12.0 — exactly the four pages whose content changed (apps, product, security, release), desktop and mobile. Inspected rather than blindly accepted: the security page renders the new control as card 07 and the footer already reads
v0.1.3 · verified release.No threshold, budget, accessibility rule or platform set was weakened.
Gates
mise exec node@22.12.0 -- npm run test:cigreen:Screenshots — separate, deliberately
The runbook re-captures every shipping shot per release, against the released tag. Per the owner's decisions this release:
The manifest already records what each shot must depict and why; the capture pass lands as its own change.