chore: bump .claude submodule pointer

Author: alexandramartinez

.claude

@@ -7,6 +7,13 @@ import remarkCallouts from './src/lib/remark-callouts.mjs';
 import rehypeTables from './src/lib/rehype-tables.mjs';
 import rehypeLinkExternal from './src/lib/rehype-link-external.mjs';
 import shikiCodeTitle from './src/lib/shiki-code-title.mjs';
+import { scheduledPostSlugs, postSlugFromUrl } from './src/lib/scheduled-slugs.mjs';
+
+// Scheduled (future-dated) posts build a `noindex` teaser page for shareable pre-publish previews
+// (see getRenderablePosts in src/lib/content.ts) but must NOT appear in the sitemap until they
+// reveal — otherwise the deploy guard in .github/workflows/deploy.yml would treat the teaser URL as
+// already-live and never deploy the pubDate reveal. Frozen once at config load (= build start).
+const scheduled = scheduledPostSlugs();
 
 // https://astro.build/config
 export default defineConfig({
@@ -19,7 +26,16 @@ export default defineConfig({
     '/post/getting-started-with-anypoint-code-builder':
       '/post/getting-started-with-anypoint-code-builder-in-vs-code-beginner-guide',
   },
-  integrations: [mdx(), sitemap()],
+  integrations: [
+    mdx(),
+    sitemap({
+      // Drop scheduled posts' teaser URLs; keep everything else. See `scheduled` above.
+      filter: (url) => {
+        const slug = postSlugFromUrl(url);
+        return !(slug && scheduled.has(slug));
+      },
+    }),
+  ],
   vite: {
     plugins: [tailwindcss()],
   },

astro.config.mjs

@@ -0,0 +1,33 @@
+---
+/**
+ * "Coming soon" panel shown IN PLACE of the article body on a scheduled post's teaser page
+ * (post/[slug].astro, when `scheduled`). The page itself returns 200 with the correct OG card so a
+ * pre-publish LinkedIn/social share previews correctly; this panel is what a curious early click
+ * sees instead of the (embargoed) body. Reuses the dashed-panel idiom + the `calendar` icon already
+ * used elsewhere; semantic tokens only, so it works in both themes. See getRenderablePosts /
+ * isPostScheduled in src/lib/content.ts.
+ */
+import Icon from '@/components/Icon.astro';
+import { formatDate } from '@/lib/content';
+
+interface Props {
+  /** The instant the article goes live (post.pubDate). Rendered in UTC to match the rest of the site. */
+  pubDate: Date;
+}
+const { pubDate } = Astro.props;
+---
+<div class="my-10 rounded-xl border border-dashed border-default p-8 text-center">
+  <Icon name="calendar" class="mx-auto mb-3 h-6 w-6 text-accent" />
+  <p class="text-lg font-semibold">This article is scheduled</p>
+  <p class="mt-2 text-muted">
+    It goes live on <time datetime={pubDate.toISOString()}>{formatDate(pubDate)}</time>.
+    In the meantime, see
+    <!-- WCAG 1.4.3 + 1.4.1: this link sits OUTSIDE `.prose`, so it doesn't inherit the
+         `.prose :where(a)` --accent-strong rule. Plain `--accent` (.text-accent) is only 3.46:1 on
+         white → fails AA 4.5:1 for normal text in the LIGHT theme; and a color-only-at-rest link
+         (hover-only underline) fails 1.4.1 since accent-vs-muted-text is ~1.6:1, well under G183's
+         3:1. Fix: --accent-strong (5.03:1 light / 9.89:1 dark) + a PERSISTENT underline as the
+         non-color affordance. -->
+    <a href="/calendar" class="font-medium text-[var(--accent-strong)] underline underline-offset-2 hover:no-underline">what's coming next</a>.
+  </p>
+</div>

src/assets/blog/acb-field-no-fx-button-set-dynamic-value-with-xml.png

@@ -0,0 +1,143 @@
+---
+title: "No fx button on an ACB field? Set a dynamic value in the XML"
+description: >-
+  A field in Anypoint Code Builder has no fx button? Set the dynamic value in the flow XML with a
+  #[] expression, and read properties with Mule::p() instead of ${}.
+pubDate: 2026-07-24
+category: Guides
+tags: [MuleSoft, Anypoint Code Builder, DataWeave, Visual Studio Code]
+heroImage: ../../assets/blog/acb-field-no-fx-button-set-dynamic-value-with-xml.png
+faqs:
+  - question: "Why does a field in Anypoint Code Builder have no fx button?"
+    answer: "Two common reasons. Not every field in a connector is expression-enabled in the UI, so some are exposed only as plain text inputs and the visual editor never renders the fx toggle next to them, even though the attribute still accepts a runtime expression. It can also be the connector version, since which fields expose the fx button is defined by the connector itself, so an older version may be missing it on a field a newer release has fixed. It's worth checking Exchange or your `pom.xml` for a newer version first."
+  - question: "How do I set a dynamic value on a field that has no fx button?"
+    answer: "Open the flow's `.xml` file directly and set the attribute by hand with a DataWeave expression wrapped in `#[ ]`, for example `path=\"#[vars.apiVersion ++ '/orders/' ++ payload.orderId]\"`. Everything inside `#[ ]` is DataWeave evaluated at runtime, which is what makes the value dynamic. Replace `path` with the actual attribute name for your connector field."
+  - question: "Is editing the flow XML directly safe, or does it bypass the runtime?"
+    answer: "It's safe. Setting the attribute in the XML is equivalent to what the fx button would have produced, so you're not working around the runtime, just reaching the same setting a different way. After you save, the value shows up on the component in the visual view and the flow runs with your expression."
+  - question: "How do I use a value from a properties file inside the expression?"
+    answer: "Read it with the `Mule::p('property.name')` function inside the `#[ ]`. `Mule::p()` reads the value of a Mule application property from your `.yaml` or `.properties` files (and also system properties or environment variables), so you can treat it like any other DataWeave value, for example `#[Mule::p('orders.api.basePath') ++ payload.orderId]`."
+  - question: "When should I use ${property} versus #[Mule::p('property')]?"
+    answer: "Use `${property}` when a field takes a plain, standalone property value. Switch to `#[Mule::p('property')]` the moment you need to concatenate or transform it, because `${...}` is a static placeholder, not a DataWeave expression, so you can't join it with `++` or mix it with the payload. Both read the same property; only the second is a real DataWeave expression you can build on."
+draft: false
+---
+
+There was a question in the MuleSoft Community Slack workspace about a wall people hit in **Anypoint
+Code Builder (ACB)**: you want to pass a *dynamic* value into a component field, but that field has
+no **fx** button. The fx button (sometimes described as the "f" button) is what flips a field into
+expression mode so you can type DataWeave. No button, no obvious way to make the value dynamic from
+the UI.
+
+The good news: the restriction is only in the visual editor. The underlying Mule XML has no such
+limit, so you can set the value yourself.
+
+## TL;DR
+
+Open the flow's XML and set the attribute inline with a DataWeave expression wrapped in `#[ ]`:
+
+```xml
+<http:request method="GET" path="#[vars.apiVersion ++ '/orders/' ++ payload.orderId]" />
+```
+
+If the value comes from a **properties file** (`.yaml` or `.properties`), read it inside the
+expression with `Mule::p('...')` instead of the `${...}` placeholder syntax, and concatenate with
+`++`:
+
+```xml
+<http:request method="GET" path="#[Mule::p('orders.api.basePath') ++ payload.orderId]" />
+```
+
+Replace `path` with the real attribute name for your connector field. That's the whole trick. The
+rest of this post explains why it works and walks through each piece.
+
+## Why the fx button is sometimes missing
+
+Not every field in a connector is expression-enabled in the UI. Some are exposed only as plain text
+inputs, so the visual editor never renders the fx toggle next to them, even though the attribute
+behind that field will happily accept a runtime expression. It's a gap in the visual layer, not a
+limitation of the runtime.
+
+It can also come down to the **connector version**. Which fields expose the fx button is defined by
+the connector itself, so an **older version** may be missing it on a field that a newer release has
+since fixed. Before anything else, it's worth checking Exchange (or your `pom.xml`) for a newer
+version of the connector and updating it. That alone can bring the button back.
+
+Either way, the fix below works: stop fighting the UI and go one level down.
+
+## Fix it in the XML with `#[ ]`
+
+Every Mule flow is just XML. In ACB you can open the flow's `.xml` file directly and edit the
+attribute by hand. Anywhere Mule accepts an expression, you write it between `#[` and `]`:
+
+```xml
+<http:request method="GET" path="#[vars.apiVersion ++ '/orders/' ++ payload.orderId]" />
+```
+
+A few things to note:
+
+- `path` here is a stand-in. Use whatever the **actual attribute name** is for your connector's
+  field (`path`, `url`, `query`, `fileName`, and so on). Hover the field in the UI or check the
+  connector docs if you're not sure what it maps to.
+- Everything inside `#[ ]` is DataWeave, evaluated **at runtime** for each event, which is exactly
+  what "dynamic" means here. You get the full language: variables (`vars.*`), the incoming message
+  (`payload`, `attributes`), functions, and `++` for concatenation.
+- Setting the attribute in the XML is equivalent to what the fx button would have produced. You're
+  not working around the runtime, you're just reaching the same setting a different way.
+
+Once you save, switch back to the visual view. The value shows up on the component, and the flow runs
+with your expression.
+
+> [!TIP]
+> If you're not sure which attribute a UI field writes to, set a placeholder value in the visual
+> editor first, then open the XML and look for it. Now you know the exact attribute name to make
+> dynamic.
+
+## When the value lives in a properties file: use `Mule::p()`
+
+A very common case is that part of the dynamic value isn't computed from the payload but read from
+configuration, like a base URL that changes per environment. In the UI, connector fields can
+consume properties with the `${...}` placeholder syntax:
+
+```xml
+<http:request method="GET" path="${orders.api.basePath}" />
+```
+
+That works fine on its own. But the moment you need to **combine** that property with something else,
+`${...}` gets awkward, because it isn't a DataWeave expression, it's a static placeholder. You can't
+concatenate it with `++` or mix it with the payload.
+
+The clean way is to move the property *inside* the expression with the `Mule::p()` function.
+`Mule::p('property.name')` reads the value of a Mule application property (from your `.yaml` /
+`.properties` files, and also system properties or environment variables), so you can treat it like
+any other DataWeave value:
+
+```xml
+<http:request method="GET" path="#[Mule::p('orders.api.basePath') ++ payload.orderId]" />
+```
+
+Now the base path comes from configuration and the order ID comes from the payload, joined at
+runtime. Same idea works with variables or literals:
+
+```xml
+<http:request method="GET" path="#[Mule::p('orders.api.basePath') ++ '/' ++ vars.orderId]" />
+```
+
+> [!NOTE]
+> Rule of thumb: use `${property}` when a field takes a **plain, standalone** property value, and
+> switch to `#[Mule::p('property')]` the moment you need to **concatenate or transform** it. Both
+> read the same property; only the second one is a real DataWeave expression you can build on.
+
+## Quick recap
+
+- No fx button on a field just means the visual editor won't let you type an expression there. The
+  attribute still accepts one.
+- First check Exchange or your `pom.xml` for a newer connector version, since an older one can be
+  the reason the button is missing.
+- Open the flow XML and set the attribute inline: `attr="#[ your expression ]"`.
+- For values from a properties file, read them with `Mule::p('name')` inside the `#[ ]` (instead of
+  `${...}`) so you can concatenate and transform them.
+
+A small trick, but it turns "this field won't let me" into "this field does exactly what I need."
+
+I hope this was helpful.
+
+💬 Prost! 🍻

src/components/ScheduledNotice.astro

@@ -1,19 +1,30 @@
-import { describe, it, expect, vi } from 'vitest';
+import { describe, it, expect, vi, afterEach } from 'vitest';
 
 // Stub the two Astro-only imports that content.ts pulls in transitively, so this pure
 // data helper can be unit-tested off the build:
-//   - astro:content — content.ts calls getCollection('blog', …). Return [] posts so the
-//     calendar's VIDEO branch is what we assert. (The article branch is exercised elsewhere.)
+//   - astro:content — content.ts calls getCollection('blog', filter). The mock APPLIES the filter
+//     callback to `blogFixtures` (default [] → the calendar tests below see no posts, unchanged),
+//     so getPosts/getRenderablePosts can be exercised on real fixtures. Referenced lazily (only
+//     when getCollection is invoked at test time, after `blogFixtures` is assigned) — no TDZ.
 //   - @/content.config — only CATEGORIES/TAGS are used, and only by OTHER helpers; stub it so
 //     the real config's zod schema + glob loader don't evaluate at import time.
+let blogFixtures: any[] = [];
 vi.mock('astro:content', () => ({
-  getCollection: vi.fn(async () => []),
+  getCollection: vi.fn(async (_name: string, filter?: (e: any) => boolean) =>
+    filter ? blogFixtures.filter(filter) : blogFixtures.slice()
+  ),
 }));
 vi.mock('@/content.config', () => ({ CATEGORIES: [], TAGS: [] }));
 
-import { upcomingCalendarItems } from './content';
+import { upcomingCalendarItems, isPostScheduled } from './content';
 import { VIDEOS, isScheduled } from '@/data/videos';
 
+/** Minimal blog entry shape the pure helpers read (id + data.pubDate + data.draft). */
+const makePost = (id: string, iso: string, draft = false): any => ({
+  id,
+  data: { pubDate: new Date(iso), draft },
+});
+
 describe('upcomingCalendarItems — never drifts from the scheduling gate', () => {
   // The bug class this whole seam guards against: the calendar hand-copied the "is it in the
   // future?" comparison instead of sharing it. This pins the property that made drift possible —
@@ -44,3 +55,87 @@ describe('upcomingCalendarItems — never drifts from the scheduling gate', () =
     expect(times).toEqual([...times].sort((a, b) => a - b));
   });
 });
+
+describe('isPostScheduled — the future-date fact (twin of video isScheduled)', () => {
+  const now = new Date('2026-07-20T00:00:00Z');
+
+  it('is false for a past pubDate', () => {
+    expect(isPostScheduled(makePost('p', '2026-07-19T00:00:00Z'), now)).toBe(false);
+  });
+
+  it('is false at the exact boundary (pubDate == now) — published, not scheduled', () => {
+    // Mirrors the getPosts gate `pubDate <= now`: at the instant it's due, it publishes.
+    expect(isPostScheduled(makePost('p', '2026-07-20T00:00:00Z'), now)).toBe(false);
+  });
+
+  it('is true for a strictly-future pubDate', () => {
+    expect(isPostScheduled(makePost('p', '2026-07-21T00:00:00Z'), now)).toBe(true);
+  });
+
+  it('reports purely on date — a future-dated DRAFT is still "scheduled" by this predicate', () => {
+    // draft is a separate lever; getRenderablePosts excludes drafts, not this fact.
+    expect(isPostScheduled(makePost('p', '2999-01-01T00:00:00Z', true), now)).toBe(true);
+  });
+});
+
+describe('getRenderablePosts — pages set = published + scheduled, minus drafts (prod)', () => {
+  afterEach(() => {
+    vi.unstubAllEnvs();
+    vi.resetModules();
+  });
+
+  // Fixtures use far-past / far-future dates so the wall-clock comparison inside getPosts is
+  // deterministic regardless of when the suite runs. getPosts/getRenderablePosts read
+  // import.meta.env.PROD at module load, so force it via stubEnv + resetModules + dynamic import.
+  const fixtures = () => [
+    makePost('past', '2000-01-01T00:00:00Z'),
+    makePost('future', '2999-01-01T00:00:00Z'),
+    makePost('future-draft', '2999-01-01T00:00:00Z', true),
+    makePost('past-draft', '2000-01-01T00:00:00Z', true),
+  ];
+
+  it('in PROD includes past + future non-draft, excludes both drafts', async () => {
+    vi.stubEnv('PROD', true);
+    vi.resetModules();
+    blogFixtures = fixtures();
+    const { getRenderablePosts } = await import('./content');
+    const ids = (await getRenderablePosts()).map((p) => p.id).sort();
+    expect(ids).toEqual(['future', 'past']);
+  });
+
+  it('in PROD differs from getPosts by exactly the scheduled (future non-draft) post', async () => {
+    vi.stubEnv('PROD', true);
+    vi.resetModules();
+    blogFixtures = fixtures();
+    const mod = await import('./content');
+    const published = (await mod.getPosts()).map((p) => p.id).sort();
+    const renderable = (await mod.getRenderablePosts()).map((p) => p.id).sort();
+    expect(published).toEqual(['past']); // getPosts hides the future one
+    expect(renderable).toEqual(['future', 'past']); // getRenderablePosts keeps it (as a teaser)
+  });
+
+  it('returns newest-first', async () => {
+    vi.stubEnv('PROD', true);
+    vi.resetModules();
+    blogFixtures = fixtures();
+    const { getRenderablePosts } = await import('./content');
+    const ids = (await getRenderablePosts()).map((p) => p.id);
+    expect(ids).toEqual(['future', 'past']); // 2999 before 2000
+  });
+
+  it('in DEV is ungated — everything (drafts + future) shows, the SAME set as getPosts', async () => {
+    // Both gates are `isProd ? … : true`, so locally a scheduled OR draft post previews and the
+    // two seams AGREE. Pins that the teaser work didn't accidentally start gating dev — the exact
+    // regression that would make `npm run dev` hide a post you're still writing.
+    vi.stubEnv('PROD', false);
+    vi.resetModules();
+    blogFixtures = fixtures();
+    const mod = await import('./content');
+    const renderable = (await mod.getRenderablePosts()).map((p) => p.id).sort();
+    const published = (await mod.getPosts()).map((p) => p.id).sort();
+    const all = ['future', 'future-draft', 'past', 'past-draft'];
+    expect(renderable).toEqual(all); // nothing gated
+    expect(published).toEqual(all); // getPosts is also ungated in dev
+    expect(renderable).toEqual(published); // …so the two sets are identical locally
+  });
+});