@omega.js/web 0.1.0

package/defaults/sample-posts/2026-01-12-welcome-to-the-blog.md

@@ -0,0 +1,26 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Welcome to the blog"
+  description: "What this space is for, what to expect here, and a note on these starter posts."
+  id: 9000001
+  image: false
+  categories: ["Company"]
+  tags: ["announcements"]
+---
+
+Every good product deserves a place to think out loud. This blog is ours: release notes that explain *why*, engineering write-ups when we learn something the hard way, and the occasional look behind the curtain.
+
+**A quick note:** the posts you're reading right now are sample content. They only appear in local development while this site has no posts of its own. Publish your first real post and they step aside automatically. Until then, they're here so the blog, categories, tags, and reading experience all render exactly the way they will with real writing in place.
+
+## What to expect
+
+We keep three promises with everything published here:
+
+1. **It's worth your time.** No filler, no keyword soup. If a post exists, it's because we had something to say.
+2. **It's honest.** When something broke, we say what broke. When we changed our minds, we say why.
+3. **It's finished.** Drafts stay drafts until they earn the publish button.
+
+If that sounds like your kind of reading, the [updates page](/updates) covers the smaller day-to-day changes, and the bigger stories land here.
+
+See you in the next post.

package/defaults/sample-posts/2026-02-03-a-field-guide-to-good-defaults.md

@@ -0,0 +1,50 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "A field guide to good defaults"
+  description: "Most settings screens are a tax on your attention. Here's how we decide what becomes a default, what becomes an option, and what gets deleted."
+  id: 9000002
+  image: false
+  categories: ["Design"]
+  tags: ["design", "product"]
+---
+
+Every option you add to a product is a question you're asking every future user. Most of them didn't come here to answer questions. They came to get something done.
+
+That's why the highest-leverage design work isn't drawing screens. It's deciding what people should never have to think about. This post is the checklist we run before anything becomes a setting.
+
+## The three buckets
+
+Every proposed option lands in exactly one bucket:
+
+| Bucket | Test | What happens |
+|---|---|---|
+| Default | 90%+ of users want the same thing | We pick it. No setting ships. |
+| Option | Real, split preference with no correct answer | A setting ships, with a strong default. |
+| Deleted | We're hedging because we couldn't decide | The feature goes back to design. |
+
+The third bucket is the one that matters. A surprising number of settings exist because a team couldn't agree, so they shipped the disagreement. That's not flexibility. That's outsourcing your job to the user.
+
+## Defaults are a promise
+
+A default isn't just a pre-filled value. It's a statement: *if you never touch this, you're doing it right.* That promise has consequences:
+
+> The default configuration is the only configuration most people will ever see. If it isn't excellent, your product isn't excellent for most people.
+
+So we test the defaults hardest. Not the power-user paths: the untouched, out-of-the-box experience. The one nobody customizes.
+
+## When an option earns its place
+
+Some options genuinely deserve to exist. The ones that survive our checklist usually share three traits:
+
+- **The preference is stable.** People who want it, want it every time. Appearance is the classic example.
+- **Both sides are right.** Dense layouts and comfortable layouts are both correct, for different people, all the time.
+- **The cost of the wrong guess is high.** If guessing wrong breaks someone's workflow, ask instead of guessing.
+
+Everything else gets a decision, not a dropdown.
+
+## The payoff
+
+Fewer settings means faster onboarding, fewer support tickets, and a settings page you can actually find things on. But the real payoff is trust: a product that behaves well untouched feels *designed*, because it was.
+
+Delete a setting this week. You almost certainly have one that's just a hedge.

package/defaults/sample-posts/2026-02-24-shipping-week-notes.md

@@ -0,0 +1,37 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Notes from a shipping week"
+  description: "Five days, one feature, no heroics: what a calm release cycle actually looks like from the inside."
+  id: 9000003
+  image: "/assets/images/core/placeholder/photo-1.jpg"
+  categories: ["Engineering"]
+  tags: ["engineering", "process"]
+---
+
+There's a myth that shipping fast requires chaos: pizza boxes, midnight deploys, a hero pulling the release across the line. Our experience is the opposite: the fastest weeks are the boring ones. Here's what one actually looks like.
+
+## Monday: cut the scope, not the corner
+
+The feature had four parts. Two were essential, one was nice, one was speculative. We shipped the two, scheduled the third, and deleted the fourth from the plan entirely. Not "later," deleted. Scope you carry is scope you pay interest on.
+
+## Tuesday–Wednesday: the quiet middle
+
+The unglamorous part nobody blogs about: writing the thing, writing the tests, reading the diff twice. The only rule that matters here is **small pull requests**. A reviewer can hold two hundred lines in their head. Nobody can hold two thousand.
+
+```text
+Rule of thumb: if the diff needs a scroll bar
+on the file list, it's two pull requests.
+```
+
+## Thursday: the boring deploy
+
+The deploy went out at 10am, because deploys go out in the morning when everyone's awake, caffeinated, and around to watch the graphs. Afternoon deploys are a bet that nothing goes wrong. Morning deploys are a plan for when it does.
+
+## Friday: write it down
+
+The release notes took an hour. That hour is the difference between users discovering the feature and the feature quietly existing. If it's not worth announcing, it probably wasn't worth building.
+
+## The takeaway
+
+No single practice here is clever. That's the point: **shipping is a habit, not an event**. The teams that release calmly every week beat the teams that release heroically every quarter, and they're a lot more fun to work on.

package/defaults/sample-posts/2026-03-17-the-case-for-one-config.md

@@ -0,0 +1,36 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "The case for one config"
+  description: "Why every surface of this product reads from a single source of truth, and what that buys you in practice."
+  id: 9000004
+  image: "/assets/images/core/placeholder/photo-2.jpg"
+  categories: ["Product"]
+  tags: ["product", "architecture"]
+---
+
+Ask any team where their brand color is defined and you'll usually get a list: the website has one, the app has another, the emails have a third that someone eyeballed in 2023. None of them are wrong, exactly. They've just drifted, the way anything defined in five places always drifts.
+
+We took the opposite bet: **one config, every surface**. The name, the colors, the links, the plans: defined once, consumed everywhere.
+
+## What "everywhere" means
+
+When a value lives in exactly one place, changing it is an edit, not a project:
+
+- Rename the product → every page title, email footer, and app menu follows.
+- Change the accent color → the site, the dashboard, and the extension repaint together.
+- Update a price → the pricing page, the checkout, and the receipts all agree.
+
+The alternative isn't hypothetical. It's the bug report that says "the website says $12 but checkout charged $15," and the afternoon you lose figuring out which one was right.
+
+## The discipline it takes
+
+Single-source-of-truth is a habit you defend, not a feature you install. The temptation is always the quick fix: hardcode it here, just this once, we'll clean it up later. Every one of those is a small loan against the system, and the interest compounds.
+
+Our rule: if you're about to type a value that already exists somewhere else, stop. Reference it. If you can't reference it, that's an architecture bug worth fixing before the feature ships.
+
+## Where it pays off most
+
+Honestly? Onboarding. A new teammate who finds one well-documented config file understands the product's shape in an afternoon. The same teammate facing five scattered definitions learns the shape the way everyone else did: by breaking something.
+
+One config. Every surface. It's less exciting than it is correct, and we'll take that trade every time.

package/defaults/sample-posts/2026-04-09-write-release-notes-people-read.md

@@ -0,0 +1,34 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Write release notes people actually read"
+  description: "Bug fixes and performance improvements is a shrug in text form. A better template, in three parts."
+  id: 9000005
+  image: "/assets/images/core/placeholder/photo-3.jpg"
+  categories: ["Guides"]
+  tags: ["writing", "process"]
+---
+
+"Bug fixes and performance improvements."
+
+Six words that say nothing, published a thousand times a day. Release notes are the one place your most engaged users voluntarily read about your work, and most products spend that attention on a shrug.
+
+Here's the template we use instead. Three parts, in order of what readers care about.
+
+## 1. What you can do now
+
+Lead with the new capability, written from the user's side of the screen. Not "Added CSV export module." Instead: "You can now export any report as a CSV." The test: could someone act on the sentence without opening the app to figure out what you meant?
+
+## 2. What got better
+
+Improvements to existing things, with the *before* included. "Search is faster" is a claim; "Search results now land in under 100ms, down from around a second" is a fact. Numbers make improvements real, and they quietly show you measure what you ship.
+
+## 3. What we fixed
+
+Bugs deserve honesty, not euphemism. "Fixed an issue where…" is fine. "Fixed the bug where exporting twice in a row could duplicate rows, sorry about that one" is better. The users who hit that bug feel *seen*, and the ones who didn't learn you own your mistakes.
+
+## The one-sentence rule
+
+If the release genuinely contains nothing worth a sentence, ask the harder question: why did it ship? Sometimes the answer is "infrastructure," and that's legitimate. Say so. But if week after week there's nothing to tell users, the release notes aren't the problem.
+
+Write the notes like someone will read them. Eventually, someone will.

package/defaults/sample-posts/2026-05-21-dark-mode-done-properly.md

@@ -0,0 +1,38 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Dark mode, done properly"
+  description: "Inverting the colors is the easy part. The last 10%, from images and shadows to charcoal instead of blue, is where dark modes are won."
+  id: 9000006
+  image: "/assets/images/core/placeholder/photo-1.jpg"
+  categories: ["Design"]
+  tags: ["design", "engineering"]
+---
+
+Every product has dark mode now. Most of them have *inverted* mode: the same interface with the values flipped, squinting back at you. Getting from there to a dark mode that feels designed comes down to a handful of decisions that don't show up in screenshots.
+
+## Charcoal, not navy
+
+The most common tell of a rushed dark theme is the blue cast: grays that drift toward navy because they were derived from a blue-tinted palette. True neutrals read calmer and let your accent color actually *be* the color. If the background has a hue, the whole interface is wearing sunglasses.
+
+## Shadows don't work in the dark
+
+Light mode communicates elevation with shadows. In dark mode there's nothing for a shadow to fall on, so elevation flips to *luminance*: the closer a surface is, the slightly lighter it gets. Panels a step lighter than the page, popovers a step lighter than panels. Subtle, but it's the difference between layered and flat.
+
+## Don't blind people with your images
+
+A pure-white diagram on a charcoal page is a flashlight. The fix costs one line: dim images slightly in dark contexts and nobody's pupils file a complaint:
+
+```css
+[data-theme='dark'] img {
+  filter: brightness(0.9);
+}
+```
+
+## Respect the preference, then remember the choice
+
+Follow the system preference by default; if someone overrides it, remember that choice per device, forever. The failure mode to avoid is the flash of the wrong theme on load. Resolve the theme *before* first paint, or the correction is the first thing users see.
+
+## The test
+
+Open your product at night, side by side with the apps people actually live in, the ones with design teams sweating these details. If yours looks flipped rather than designed, the gap is almost always one of the four things above. All four are a weekend.

package/defaults/sample-posts/2026-06-02-the-boring-deploy-is-the-good-deploy.md

@@ -0,0 +1,30 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "The boring deploy is the good deploy"
+  description: "If shipping to production raises your heart rate, the process is telling you something. Here's what it takes to make deploys a non-event."
+  id: 9000007
+  image: "/assets/images/core/placeholder/photo-2.jpg"
+  categories: ["Engineering"]
+  tags: ["engineering", "deploys"]
+---
+
+There are two kinds of teams: the ones where a deploy is a ceremony (announced in the channel, watched like a rocket launch) and the ones where nobody remembers how many times they shipped on Tuesday. The second kind wins, and not because they're braver.
+
+## Ceremony is a symptom
+
+When deploys are scary, teams deploy less. When teams deploy less, each deploy carries more changes. More changes per deploy means more ways for something to break and a harder time finding what did. The fear creates the exact conditions that justify the fear. It's a flywheel, and it spins both directions.
+
+## What boring takes
+
+Boring is earned with three unglamorous investments:
+
+- **One command.** If the runbook has more than one step, the runbook is where mistakes live. The whole path (build, verify, publish, purge) belongs behind a single verb.
+- **A dry run that tells the truth.** The rehearsal has to exercise the real pipeline against the real targets, minus the final write. A dry run that mocks half the world only rehearses your mocks.
+- **Rollback you've actually used.** An untested rollback is a wish. Roll back on purpose once a quarter, on a calm afternoon, so the muscle exists when the afternoon isn't calm.
+
+## The test
+
+Ask the newest person on the team to ship something small today. If the answer involves a checklist, a senior engineer, or the phrase "after the freeze," you don't have a deploy process. You have a ritual. Rituals are for weddings.
+
+Make it boring. Boring compounds.

package/defaults/sample-posts/2026-06-11-naming-things-a-survival-guide.md

@@ -0,0 +1,30 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Naming things: a survival guide"
+  description: "The two hard problems in computer science are cache invalidation, naming things, and off-by-one errors. This post is about the middle one."
+  id: 9000008
+  image: "/assets/images/core/placeholder/photo-3.jpg"
+  categories: ["Guides"]
+  tags: ["guides", "engineering", "culture"]
+---
+
+Every codebase carries the fossil record of its naming decisions. `utils2.js`. `NewButtonFinal`. A function called `handleData` that neither handles nor, strictly speaking, data. None of these were written by fools. They were written by smart people at 6pm. Naming fails under pressure unless you have rules that don't require judgment.
+
+## Name the thing, not the shape
+
+`items`, `data`, `info`, `payload`: these describe what something *is made of*, not what it *means*. The reader already knows it's data; everything here is data. `overdueInvoices` costs four more keystrokes and saves the next person a trip to the call site.
+
+## Verbs for functions, nouns for values
+
+A function is a promise to do something, so name the promise. `sendReceipt` beats `receipt`. And when a function's honest name turns out to be `sendReceiptAndUpdateLedgerAndNotifySlack`, the name has done its real job: it told you the function needs to be three functions.
+
+## The grep test
+
+Before committing a name, ask: if I searched for this in six months, would I find it, and *only* it? Names that collide with language keywords, framework globals, or forty other identifiers fail silently. `map` is unfindable. `regionMap` isn't.
+
+## Rename without asking permission
+
+The most underused refactor is the rename. It needs no design review, breaks no behavior, and pays out every single time someone reads the code. If you understand a thing better than its name suggests, fixing the name is not cosmetic: it's transferring your understanding to everyone who comes after.
+
+The goal was never perfect names. It's names that don't lie.

package/defaults/sample-posts/2026-06-19-your-pricing-page-is-a-product.md

@@ -0,0 +1,28 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Your pricing page is a product"
+  description: "It gets more skeptical traffic than anything else you ship, and most teams treat it like a brochure. Treat it like a product instead."
+  id: 9000009
+  image: "/assets/images/core/placeholder/photo-1.jpg"
+  categories: ["Product"]
+  tags: ["product", "business"]
+---
+
+Nobody arrives at a pricing page by accident. Every visitor is mid-decision, wallet half-open, looking for a reason to close it, or to close the tab. That makes it the highest-stakes surface you own, and the one most teams last touched two rebrands ago.
+
+## Answer the four questions fast
+
+Every pricing visitor is running the same script: *What does it cost? What do I get? What's the catch? What happens if I outgrow it?* A good page answers all four above the fold. Anything that delays those answers (mystery tiers, "Contact us" as the only number, features named after your internal jargon) reads as evasion. Evasion reads as expensive.
+
+## Compare honestly or don't compare
+
+Feature tables fail two ways: rows nobody understands ("Advanced sync engine ✓") and rows engineered so the middle column wins. Readers smell both. Write rows a customer would actually use to decide, and let your cheapest plan win the rows it honestly wins. Confidence is more persuasive than choreography.
+
+## The guarantee does heavy lifting
+
+A visible money-back guarantee converts skeptics not because anyone plans to use it, but because it signals you expect them not to. It moves the risk from their side of the table to yours. If you're confident in the product, it's the cheapest trust you'll ever buy.
+
+## Measure it like a product
+
+The pricing page has a funnel, an activation rate, and failure modes, so instrument it. Where do people leave? Which plan gets hovered and abandoned? What do support tickets ask that the page should have answered? Ship changes, watch the numbers, repeat. Brochures get reprinted; products get better.

package/defaults/sample-posts/2026-06-30-email-is-an-api-with-feelings.md

@@ -0,0 +1,28 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Email is an API with feelings"
+  description: "Transactional email is the only interface your product has that lands in someone else's house. Design it like you mean it."
+  id: 9000010
+  image: "/assets/images/core/placeholder/photo-2.jpg"
+  categories: ["Design"]
+  tags: ["design", "product", "email"]
+---
+
+Your app has one interface users visit and one that visits *them*. The second one (the receipt, the reset link, the "your export is ready") shows up in the same inbox as messages from their bank and their mother. It's judged by those standards, and most product email loses.
+
+## The subject line is the product
+
+People decide whether to open in under a second, from three signals: who it's from, what it says, and whether it smells automated. "Your invoice for June" beats "Invoice #INV-2026-06-0041 Generated". Write subjects the way you'd text a busy friend: specific, short, zero ceremony.
+
+## One email, one job
+
+The reset email exists so someone can reset a password. Every additional element (the feature banner, the social row, the "while you're here") is friction between a stressed user and the button they came for. State the job, do the job, sign off. Marketing has its own emails; don't let it colonize the transactional ones.
+
+## Design for the dark inbox
+
+Most inboxes are dark-mode now, and most product email still ships as a white card that arrives like a flashbang. Test both themes, use images that survive inversion, and remember that some clients strip your styles entirely. The plain-text fallback isn't a legacy checkbox, it's the floor your reputation stands on.
+
+## The unsubscribe test
+
+Here's the standard worth holding: every email you send should survive the question *"would a reasonable person want this?"* Receipts pass. Resets pass. "We miss you" at 3am does not. Email is a guest in someone's house. Behave like one, and you're welcome back.

package/defaults/sample-posts/2026-07-08-ship-the-docs-with-the-diff.md

@@ -0,0 +1,30 @@
+---
+layout: blueprint/blog/post
+post:
+  title: "Ship the docs with the diff"
+  description: "Documentation written 'later' is documentation written never. The only docs that stay true are the ones that travel in the same commit as the change."
+  id: 9000011
+  image: "/assets/images/core/placeholder/photo-3.jpg"
+  categories: ["Company"]
+  tags: ["culture", "engineering", "docs"]
+---
+
+Every team agrees documentation matters, the way everyone agrees flossing matters. And every team has a wiki page titled "Getting Started" that starts you toward a build system retired eighteen months ago. The gap isn't discipline. It's *distance*: the further docs live from the change that invalidates them, the faster they rot.
+
+## Later never comes
+
+"I'll document it after launch" fails for a structural reason: after launch, the knowledge is stale in *your* head too. The moment you understand a change best is the moment you finish writing it. Docs written then take minutes; docs written next quarter take an afternoon of re-derivation and still come out wrong.
+
+## Same diff or it didn't happen
+
+The rule that actually works is mechanical, not motivational: a change that alters behavior ships its doc update **in the same commit**. New flag? The reference gains a row in the same diff. Removed feature? Its section dies in the same diff. Reviewers can hold the line without archaeology, because the truth and its description arrive together or not at all.
+
+## Write for the person at 2am
+
+The reader of internal docs is usually someone mid-incident, holding a pager and a search box. Optimize for them: lead with the command, not the philosophy. State what's true *now*, never the history of how it got that way. That story lives in commit messages, where it's already written and can never drift.
+
+## One home per fact
+
+Rot accelerates when the same fact lives in three places, because no diff can update all three. Give every fact one authoritative home and point everything else at it. A link can't go stale the way a copy can.
+
+Docs aren't a genre of writing. They're a property of the diff.

package/defaults/sample-team/avery-quinn.md

@@ -0,0 +1,22 @@
+---
+layout: blueprint/team/member
+meta:
+  index: false
+
+member:
+  id: avery-quinn
+  name: Avery Quinn
+  position: Founding Engineer
+  excerpt: "Avery built the first prototype in a weekend and has been un-building it properly ever since."
+  image: "/assets/images/core/placeholder/photo-1.jpg"
+  location: Portland, OR
+  joined: 2019-06-17
+  links:
+    - id: github
+      title: GitHub
+      url: https://github.com
+---
+
+Hey, I'm Avery, a sample profile that only shows up in local development. Add a real `_team/` member and I disappear.
+
+I care about boring infrastructure, fast builds, and deleting more code than I write.

package/defaults/sample-team/jordan-reyes.md

@@ -0,0 +1,25 @@
+---
+layout: blueprint/team/member
+meta:
+  index: false
+
+member:
+  id: jordan-reyes
+  name: Jordan Reyes
+  position: CEO
+  excerpt: "Jordan sets the direction and still reviews every release note before it ships."
+  image: "/assets/images/core/placeholder/photo-2.jpg"
+  location: Austin, TX
+  joined: 2019-03-04
+  links:
+    - id: linkedin
+      title: LinkedIn
+      url: https://www.linkedin.com
+    - id: github
+      title: GitHub
+      url: https://github.com
+---
+
+Hi, I'm Jordan, sample content standing in so the team page renders the way it will with your real people on it. I appear only in local development and step aside the moment you add your own `_team/` profiles.
+
+Around here I own the roadmap, write the changelog nobody asked for, and make sure "simple" stays a feature.

package/defaults/sample-team/riley-nakamura.md

@@ -0,0 +1,22 @@
+---
+layout: blueprint/team/member
+meta:
+  index: false
+
+member:
+  id: riley-nakamura
+  name: Riley Nakamura
+  position: Support Lead
+  excerpt: "Riley answers faster than the status page and remembers every customer by name."
+  image: "/assets/images/core/placeholder/photo-3.jpg"
+  location: Seattle, WA
+  joined: 2021-08-02
+  links:
+    - id: x-twitter
+      title: X
+      url: https://x.com
+---
+
+Hi, I'm Riley, one of the sample teammates who keep this page alive in local development. We bow out as soon as your real team arrives in `_team/`.
+
+Support isn't a queue, it's the product's second first impression.

package/defaults/sample-team/sam-okafor.md

@@ -0,0 +1,22 @@
+---
+layout: blueprint/team/member
+meta:
+  index: false
+
+member:
+  id: sam-okafor
+  name: Sam Okafor
+  position: Design Lead
+  excerpt: "Sam owns the type scale, the spacing scale, and every opinion about both."
+  image: "/assets/images/core/placeholder/photo-1.jpg"
+  location: Chicago, IL
+  joined: 2020-01-13
+  links:
+    - id: website
+      title: Portfolio
+      url: https://example.com
+---
+
+I'm Sam, sample content while your team page waits for its real people. Local development only; your first `_team/` profile replaces the whole sample crew.
+
+Good design is mostly restraint. The rest is kerning.

package/defaults/sample-updates/v1.0.0.md

@@ -0,0 +1,28 @@
+---
+layout: blueprint/updates/update
+update:
+  version: "1.0.0"
+  title: "Hello, world"
+  date: 2026-04-22
+  summary: "The first public release. Everything before this was a promise; this is the product."
+  highlights:
+    - text: "First release"
+    - text: "Core workflow"
+    - text: "Free plan"
+---
+
+## The first release
+
+After a private beta with a patient group of early users (thank you, you know who you are), version 1.0 is live for everyone.
+
+## What's in the box
+
+- **The core workflow**, end to end: create, organize, share, done.
+- **A free plan** that's actually usable, not a demo with a countdown timer.
+- **Sign in with email or Google**, sessions that survive a browser restart, and password reset that works at 2am.
+
+## What's next
+
+Team features are already in progress (spoiler: workspaces), and data export is high on the list. Your data should never feel locked in. The roadmap is shaped by what you tell us, so keep the feedback coming from the app's Feedback button.
+
+Onward.

package/defaults/sample-updates/v1.1.0.md

@@ -0,0 +1,27 @@
+---
+layout: blueprint/updates/update
+update:
+  version: "1.1.0"
+  title: "The export you asked for"
+  date: 2026-05-30
+  summary: "Full data export in open formats, scheduled reports, and a quieter notification system that only speaks when spoken to."
+  highlights:
+    - text: "Data export"
+    - text: "Scheduled reports"
+    - text: "Notification controls"
+---
+
+## New
+
+- **Export everything.** Your complete data as CSV or JSON, generated in the background and delivered to your inbox. Your data is yours; leaving should be easy, and that's what makes staying a choice.
+- **Scheduled reports.** Any saved view can email itself to you daily, weekly, or monthly.
+
+## Improved
+
+- **Notification controls.** Per-event toggles instead of one all-or-nothing switch. The default set is deliberately quiet: things you did don't notify you; things done to you do.
+- Loading states everywhere got skeletons instead of spinners: same wait, less waiting-feeling.
+
+## Fixed
+
+- Currency formatting for locales that use comma decimals. €1.234,56 now renders the way your accountant expects.
+- Password reset emails occasionally took the scenic route; they're instant now.

package/defaults/sample-updates/v1.2.0.md

@@ -0,0 +1,27 @@
+---
+layout: blueprint/updates/update
+update:
+  version: "1.2.0"
+  title: "Team workspaces"
+  date: 2026-06-18
+  summary: "Invite your whole team, control who can see what with roles, and stop forwarding screenshots of the dashboard."
+  highlights:
+    - text: "Workspaces"
+    - text: "Roles & permissions"
+    - text: "Activity log"
+---
+
+## New
+
+- **Workspaces.** One account, many teammates. Invite by email from Settings → Team; everyone sees the same projects with their own login.
+- **Roles.** Owners manage billing and members; editors change things; viewers look without touching. Defaults are sensible, overrides are per-project.
+- **Activity log.** Every meaningful change (who, what, when) in one searchable stream. Auditors love it. So will you, eventually, at the worst possible time.
+
+## Improved
+
+- Invitation emails land with your workspace name and logo, so teammates know it's not phishing.
+- Session handling across devices: signing out on one device no longer signs you out everywhere unless you ask it to.
+
+## Fixed
+
+- The plan-limit banner could appear one member too early. It counts correctly now.

package/defaults/sample-updates/v1.3.0.md

@@ -0,0 +1,28 @@
+---
+layout: blueprint/updates/update
+update:
+  version: "1.3.0"
+  title: "Dark mode, faster search, and the little things"
+  date: 2026-07-10
+  summary: "The whole app now follows your system theme (or your override), search returns results as you type, and a round of paper cuts got sanded down."
+  highlights:
+    - text: "Dark mode"
+    - text: "Instant search"
+    - text: "27 fixes"
+---
+
+## New
+
+- **Dark mode everywhere.** Follows your system preference out of the box; override it from Settings → Appearance and we remember your choice per device.
+- **Instant search.** Results render as you type, with your most-visited pages ranked first. Press `⌘K` anywhere.
+
+## Improved
+
+- Export jobs now email you when they finish instead of making you babysit the spinner.
+- Invoices show the plan and period directly in the list. No more opening each PDF to find March.
+
+## Fixed
+
+- Timezone drift that could show yesterday's date on today's activity (reported by three of you within an hour, thank you).
+- The settings sidebar no longer loses your scroll position when saving.
+- 25 more small fixes across billing, onboarding, and the mobile web layout.