Add news/highlights section

[serjikibm]

fixes #19

This is a simple take, reusing the existing blogs markdown approach to replace the feature strip with a new section that has some subtle coloring to call out attention to events, integration in docs and releases.

This is a simpler take to get the content out there for now in a simpler and known way.

Draft PR 20 has another take. We should just pick one and merge to not miss the opportunity to call out new content, and make the site somewhat dynamic with new content.

Before the change

After the change

[serjikibm]

The CI errors seem like a timeout on the ibm.biz link checks in the blogs

[ajbozarth]

I like this refactor more than the one in #20 but I have questions on the content that would block merging as is:

• what determines a news item?
• do we only keep three at a time?
• why not just show blogs here instead of at the bottom?
• or we could combine news items like these with a outside link along side blogs
• what would a news item lifecycle be?

[ajbozarth]

I'll take a technical look at the code before EOD (to many ongoing threads at the moment)

[serjikibm]

I'll take a technical look at the code before EOD (to many ongoing threads at the moment)

Thanks @ajbozarth no rush. It can wait till Monday. The MCP comment was quite critical.

[ajbozarth]

Code is structurally sound: lib/news.ts mirrors lib/blogs.ts, NewsHighlights stays a Server Component, CSS variables resolve, types are clean. The blockers are around content lifecycle and a few content/code-level fixes (inline).

Cap and lifecycle. The grid is repeat(auto-fit, minmax(260px, 1fr)) against a ~1136px-wide strip, fitting up to 4 cards per row at desktop. 3 items renders as a clean single row. 5 items renders as one row of 4 + one orphan card stretched across the full width on a second row, which looks broken — the same orphan-row issue .blog-grid (globals.css L530-535) avoided by using real borders rather than the gap: 1px; background: var(--border) trick. getAllNews() returns everything in content/news/ with no slice, so the strip will visibly break the moment a fifth news item lands.

Strawman: trim to 3-4 in page.tsx (mirrors recent = blogs.slice(0, 3)), no /news archive page. News is transient — releases live on GitHub releases, events go stale after their date — so an archive of old news is lower value than a blog archive of evergreen writing. If volume ever justifies a discoverable list, /news can reuse .blog-grid later.

If we instead want unbounded news on the homepage, the strip needs the orphan-row fix before merge (inline comment below).

Sort behavior. Pure descending by date means a future-dated Event leads ahead of a more recent Release. Probably right for an events-first framing, but worth confirming intent rather than inheriting it from the sort.

Doc gap. AGENTS.md documents content/blogs/ schema but not content/news/. Adding the front-matter shape (title, date, category, excerpt, url, source) will save the next contributor a source read.

[ajbozarth]

I've not quite content with how Claude summarized my thoughts above so here's a better attempt manually:

Though this is pretty good technically I think we need to establish a lifecycle for news. As part of this lifecycle we should need to establish the following:

• do we cap the news displayed on the landing page? If so to what number (3 or 4 fit on one line)
• if we are capping the list, what should be displayed? latest dates? manual order?
• how should dates work, the current examples have both past and future, but eventually this future one will be in the past
• should we have a news page like blogs so a visitor can go look at older news? (this would alleviate the lifecycle on landing page issue)
• should we periodically remove old news?

No matter what we choose we should document this just like I did with the blog process

[planetf1]

Agree with Alex's technical comments above. My thought is particularly around the lifecycle and positioning of blog vs news - as Alex mentioned just above

They are very similar in many ways -- can we clearly articulate the difference?
Wouldn't a news article about a conference, presentation, team news, release really be the same as a blog?
What are the characteristics driving the difference? Is it that we want to 'pin' a post (that would be an alternative approach)? Or do we want multiple views of blog streams in different areas of the page (could seem cluttered)?

[ajbozarth]

This LGTM from a technical side, we just need to consolidate around a preliminary process and document it. We should be able to discuss and finalize it at Thursday dev-rel call

[planetf1]

Two small nits not yet raised — everything else already covered well by the existing thread. Happy to see this land.

[planetf1]

Leftover commented-out line. With background absent, gap: 1px just produces empty space rather than the border-trick — which is fine based on the screenshot, but the comment is just noise now. Safe to delete:

Suggested change

gap: 1px;

[planetf1]

The getter defaults to '' if source is missing from frontmatter, so this field is optional in practice. Reflect that in the interface to avoid a misleading required-field guarantee:

Suggested change

	source: string;
	source?: string;