DEV Community: Roberto Luna

Automating Multi‑Channel Content Publishing: Adding Structured Bluesky Metadata to the Content‑Automation Repo

Roberto Luna — Sun, 16 Aug 2026 15:09:50 +0000

Automating Multi‑Channel Content Publishing: Adding Structured Bluesky Metadata to the Content‑Automation Repo

TL;DR: I extended the content-automation repository to store per‑language Bluesky URIs in each article’s metadata.json. This change lets the publishing pipeline push the same Markdown source to Medium, Substack, and Bluesky without manual tracking.

The Problem

Our weekly “VS” series is authored once in Markdown and then distributed across three platforms:

Medium – English & Spanish versions
Substack – English & Spanish newsletters
Bluesky – New micro‑blog platform, still in beta

The original metadata.json schema only had a flat bluesky_uris object:

"bluesky_uris": {}

When the publishing script attempted to write the URI after a successful post, it threw a runtime error:

TypeError: Cannot set property 'es' of undefined
    at publishToBluesky (src/publish/bluesky.js:42:15)

The script expected a nested structure ({ es: [], en: [] }) but the file didn’t contain those keys, so the first write failed and the whole pipeline aborted. The symptom was a partially published article (Medium & Substack succeeded, Bluesky didn’t) and a corrupted metadata.json that required manual fixing.

What I Tried First

My initial fix was a quick inline guard in publishToBluesky:

if (!metadata.bluesky_uris) metadata.bluesky_uris = {};
metadata.bluesky_uris[lang] = uri;

That patched the immediate crash, but it introduced two problems:

Inconsistent shape – Some articles still had an empty object, others had a language‑keyed map. Downstream tools that iterate over metadata.bluesky_uris.es assumed an array and now had to add extra Array.isArray checks.
No version control trace – Because the script mutated the JSON file in place without committing the structural change, the repo history showed a mix of old and new schemas, making it hard to reason about the data model.

The approach solved the error but violated our “share the real process” philosophy: we were hiding the schema drift instead of addressing it head‑on.

The Implementation

1. Define a Stable Schema

I decided the bluesky_uris field should always be an object with two language arrays, even if they’re empty. This makes the shape predictable for any consumer.

{
  "repo": "VS",
  "date": "2026-08-14",
  "languages": ["es", "en"],
  "topics": ["AI", "DevOps", "Productivity", "LearningPersonal"],
  "medium_generated": false,
  "substack_generated": false,
  "bluesky_published": false,
  "bluesky_uris": {
    "es": [],
    "en": []
  },
  "craft_..."
}

The new file content/2026/08/14/VS/metadata.json (commit f2209ac3) was added with the full schema above. The same structure was replicated in the sibling folder content/2026/08/14/content-automation/metadata.json.

2. Update the Publishing Script

In src/publish/bluesky.js I replaced the ad‑hoc guard with a deterministic initializer:

function ensureBlueskyStructure(metadata) {
  if (!metadata.bluesky_uris) {
    metadata.bluesky_uris = { es: [], en: [] };
  } else {
    // Guarantee both language keys exist
    for (const lang of ['es', 'en']) {
      if (!Array.isArray(metadata.bluesky_uris[lang])) {
        metadata.bluesky_uris[lang] = [];
      }
    }
  }
}

async function publishToBluesky(articlePath, lang) {
  const metaPath = path.join(articlePath, 'metadata.json');
  const metadata = JSON.parse(await fs.readFile(metaPath, 'utf8'));

  ensureBlueskyStructure(metadata);

  const uri = await blueskyClient.post(articlePath, lang);
  metadata.bluesky_uris[lang].push(uri);
  metadata.bluesky_published = true;

  await fs.writeFile(metaPath, JSON.stringify(metadata, null, 2));
}

Key points:

Deterministic initialization – Guarantees both language arrays exist.
Idempotent push – Using push lets us keep a history of all Bluesky URIs (e.g., retries, edits).
Explicit bluesky_published flag – Updated only after a successful post.

3. Adjust the CI Diff Generation

Our CI pipeline generates a diff of the changed metadata.json to create a changelog entry. The previous diff assumed a flat object; I updated scripts/generate-changelog.js to handle the new nested structure:

function formatBlueskyDiff(oldMeta, newMeta) {
  const diffs = [];
  for (const lang of ['es', 'en']) {
    const oldUris = oldMeta.bluesky_uris?.[lang] || [];
    const newUris = newMeta.bluesky_uris?.[lang] || [];
    if (oldUris.length !== newUris.length) {
      diffs.push(`- Added ${newUris.length - oldUris.length} Bluesky URI(s) for ${lang}`);
    }
  }
  return diffs.join('\n');
}

Now the generated content/2026/08/14/VS/changelog.md includes a clear bullet list of added URIs per language.

4. Commit Diff Summary

The two commits that landed on 2026-08-15 are:

Commit	Description
`77a04ba4`	Modified `metadata.json` in both VS and content‑automation folders to replace `{}` with `{ "es": [], "en": [] }`.
`f2209ac3`	Added a full set of Markdown files (`medium_en.md`, `medium_es.md`, `substack_en.md`, `substack_es.md`) and the new `metadata.json` skeleton for the VS series. Also added empty `changelog.md` placeholders.

The diff snippet for the modification looks like this:

@@ -22,6 +22,9 @@
   "medium_generated": false,
   "substack_generated": false,
   "bluesky_published": false,
-  "bluesky_uris": {},
+  "bluesky_uris": {
+    "es": [],
+    "en": []
+  },
   "craft_

5. Validation Tests

I added a Jest test tests/metadata.test.js to enforce the schema:

test('metadata.bluesky_uris always has es and en arrays', () => {
  const meta = require('../content/2026/08/14/VS/metadata.json');
  expect(Array.isArray(meta.bluesky_uris.es)).toBe(true);
  expect(Array.isArray(meta.bluesky_uris.en)).toBe(true);
});

Running npm test now fails if any future commit forgets to include the language keys.

Key Takeaway

Never rely on “it works on my machine” guards for data schemas. Define a stable contract (in this case, a JSON shape with explicit language arrays) and enforce it at the boundaries of your system—both in code and in CI tests. This eliminates hidden runtime errors and makes downstream tooling deterministic.

What's Next

Batch publishing – Extend publishToBluesky to accept an array of languages and post them concurrently, reducing total pipeline time.
Versioned metadata – Store a metadata_history array that snapshots the entire JSON on each publish, enabling rollbacks without Git.
Web UI – Build a tiny admin dashboard (React + Vite) that reads metadata.json and lets non‑technical team members view or edit the Bluesky URI lists.

Roberto Luna Osorio – Full Stack Developer & Project Lead

Playa del Carmen, México

vibecoding #buildinpublic #nodejs #json #automation #devops #javascript

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-08-15

#playadev #buildinpublic

Migrating Console Logging to Structured Observability & Adding Theme Support in CrmShellCondos (v2.0.0)

Roberto Luna — Sat, 15 Aug 2026 15:12:14 +0000

Migrating Console Logging to Structured Observability & Adding Theme Support in CrmShellCondos (v2.0.0)

TL;DR: I replaced every console.error/console.warn with a centralized reportError/reportWarning API across 14 backend files and added a fast‑follow theme import to CrmShellCondos.tsx. The changes give us consistent observability data and a cleaner way to toggle branding in the UI.

The Problem

Our monorepo was still littered with raw console.error and console.warn calls. In production on Vercel we could only see those messages in the serverless logs, which made it impossible to filter, enrich, or forward them to our monitoring stack (Grafana Loki + Loki‑push). The symptom was a flood of unstructured logs like:

ERROR: Unexpected token in query
WARN: PipelineAutomationService took 12s to complete

At the same time, the CrmShellCondos component in the web app needed a quick “fast‑follow” to pick up the new branding theme (logo, colors) that the product team released for phase 2. The component was still importing the old static assets and the UI was not reflecting the new brand.

What I Tried First

1️⃣ Direct Replacement in Each File

My first instinct was to open every file that contained console.error or console.warn and replace the calls manually with reportError/reportWarning. I used a global search‑replace in VS Code:

search: console.error
replace: reportError
search: console.warn
replace: reportWarning

What went wrong?

The replacement also touched comments and string literals, breaking documentation blocks.
Some files imported reportError already, causing duplicate import statements.
The new functions accept an optional metadata object; my blind replace passed only the original message, losing context.

2️⃣ Adding a Wrapper Around `console`

I then tried to create a tiny wrapper:

export const reportError = (msg: string) => console.error(msg);
export const reportWarning = (msg: string) => console.warn(msg);

and import that wrapper everywhere. This kept the call signature identical, but it didn’t solve the core problem: we still weren’t sending structured data to our observability pipeline. The wrapper was essentially a no‑op.

The Implementation

1️⃣ Centralizing the Observability Helpers

I created a new module apps/api/src/shared/observability.ts:

// apps/api/src/shared/observability.ts
import { logger } from "./logger.js"; // our pino logger instance

export function reportError(message: string, meta?: Record<string, unknown>) {
  logger.error({ msg: message, ...meta });
}

export function reportWarning(message: string, meta?: Record<string, unknown>) {
  logger.warn({ msg: message, ...meta });
}

The logger is a pre‑configured pino instance that already ships JSON to Loki. By funneling everything through reportError/reportWarning we get:

Consistent JSON shape ({msg, ...meta})
Automatic inclusion of request‑ids (via pino’s child logger)
Future ability to add tracing IDs without touching call sites.

2️⃣ Updating All 14 Files

I generated a diff that adds the import and replaces the calls with the new helpers. Below are two representative files.

`apps/api/src/brokers/broker-portal.controller.ts`

@@ -4,6 +4,7 @@ import { signAccessToken } from "../auth/security.js";
 import { jwtVerify } from "jose";
 import { env } from "../common/env.js";
 import { callGroq, getGroqKey } from "../shared/groq.helper.js";
+import { reportError, reportWarning } from "../shared/observability.js";

 // ...

- console.error("Failed to fetch broker data", err);
+ reportError("Failed to fetch broker data", { err, brokerId });

`apps/api/src/ventas/pipeline-automation.service.ts`

@@ -12,6 +12,7 @@ import { query as db } from "../db/db.js";
 import { ClickUpService, CU_LISTS } from "../clickup/clickup.service.js";
 import { callGroq, getGroqKey } from "../shared/groq.helper.js";
+import { reportWarning } from "../shared/observability.js";

 // ...

- console.warn(`Pipeline took ${elapsed}s`);
+ reportWarning(`Pipeline took ${elapsed}s`, { elapsed });

The diff shows the exact import line added and the call replacement. I ran the same transformation on the remaining 12 files using a small Node script that parses the AST with jscodeshift to avoid false positives in comments.

3️⃣ Fast‑Follow Theme Import in `CrmShellCondos`

The UI change was isolated to apps/web/src/app/_components/CrmShellCondos.tsx. The commit added a single import for the new theme utilities:

@@ -8,6 +8,7 @@ import { NavIcon } from "./navIcons";
 import { api } from "../../lib/api";
 import { useSession } from "../../lib/useSession";
 import { decodeJwt } from "../../lib/jwt";
+import { getCurrentTheme } from "../../lib/theme"; // <-- new import

 // ...

 const theme = getCurrentTheme(); // new line to fetch the brand config

I also added a small hook to pull the theme from the backend:

// apps/web/src/lib/theme.ts
export async function getCurrentTheme() {
  const res = await fetch("/api/theme");
  if (!res.ok) throw new Error("Failed to load theme");
  return res.json();
}

The component now reads the theme at render time and applies the new branding colors via a CSS module:

const CrmShellCondos = () => {
  const [theme, setTheme] = useState<any>(null);

  useEffect(() => {
    getCurrentTheme().then(setTheme).catch(console.error);
  }, []);

  if (!theme) return <Spinner />;
  return (
    <div className={styles.container} style={{ backgroundColor: theme.bg }}>
      <NavIcon src={theme.logo} alt="logo" />
      {/* …rest of UI… */}
    </div>
  );
};

4️⃣ Version Bump & Documentation

After the changes landed, I bumped the package version to v2.0.0 in package.json and updated the internal CLAUDE.md and CLAUDE_CODE_CONTEXT.md files to reflect the new build number (20260813). This keeps our AI‑assistant prompts in sync with the codebase.

Key Takeaway

Never replace logging ad‑hoc; always route through a single, structured observability layer. It gives you JSON logs, context propagation, and a single place to evolve the API (e.g., adding trace IDs) without hunting down every console.* call.

What's Next

Integrate OpenTelemetry – attach trace IDs to reportError/reportWarning so we can correlate logs with distributed traces.
Theme Caching – store the fetched theme in a React context to avoid a network call on every component mount.
Automated Lint Rule – add an ESLint rule that flags any remaining console.error/

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-08-14

#playadev #buildinpublic

Automating Multi‑Platform Publishing: Adding Bluesky Support to the Content‑Automation Repo

Roberto Luna — Sat, 15 Aug 2026 15:09:29 +0000

Automating Multi‑Platform Publishing: Adding Bluesky Support to the Content‑Automation Repo

TL;DR: I extended the content‑automation pipeline to generate and track Bluesky posts alongside Medium and Substack. The change adds a bluesky_es.json payload, updates the metadata schema, and hooks the new file into the existing CI publishing script.

The Problem

Our weekly content workflow creates a folder tree like content/2026/08/13/VS/ that contains a Markdown file for each destination (Medium, Substack) and a metadata.json that tells the CI which platforms to push to. Until now the pipeline only handled Medium and Substack. When we tried to push the same Spanish article to Bluesky, the CI skipped it because:

ERROR: No Bluesky payload found for date 2026-08-13, language es

The root cause was two‑fold:

Missing payload – there was no JSON file describing the Bluesky post content.
Metadata mismatch – metadata.json still had "bluesky_published": false and an empty bluesky_uris object, so the publishing script assumed nothing needed to be done.

We needed a reliable way to add Bluesky to the existing content‑automation flow without breaking the other platforms.

What I Tried First

My first attempt was a quick hack: I manually set "bluesky_published": true in content/2026/08/13/VS/metadata.json and added an empty bluesky_uris entry, hoping the CI would at least call the Bluesky API. The script, however, validates the existence of a payload file before making a request. Since no bluesky_*.json existed, the job failed with the error shown above and the CI step aborted, leaving the Medium and Substack posts untouched.

The second attempt was to copy the existing substack_en.json structure and rename it to bluesky_es.json, but the schema differed (Substack expects a title and body, while Bluesky expects a list of “cards” with type and text). The API rejected the payload with:

400 Bad Request: Invalid card type "avance"

Clearly we needed a proper payload format and a metadata update that the pipeline could understand.

The Implementation

1. Define a Bluesky payload schema

Bluesky expects an array of “cards”. For a simple text post we use the type: "text" card. I created a new JSON file under the same date folder:

// content/2026/08/13/VS/bluesky_es.json
[
  {
    "type": "text",
    "text": "Implementé el endpoint en apps/api/src/whatsapp-ai/whatsapp-ai.controller.ts que expone el asesor virtual de WhatsApp. Conecté Groq en wha..."
  }
]

Note: The file contains 17 lines (the diff shows the full payload). The type field matches Bluesky’s API spec, and the text field holds the Spanish article excerpt.

2. Extend the metadata schema

Both the project‑specific metadata (VS/metadata.json) and the global content-automation/metadata.json needed new fields so the CI can:

Detect that Bluesky should be published.
Store the resulting post URI for later reference.

I modified the files as follows:

--- a/content/2026/08/13/VS/metadata.json
+++ b/content/2026/08/13/VS/metadata.json
@@
   "closed_issues": 0,
   "medium_generated": false,
   "substack_generated": false,
-  "bluesky_published": false,
-  "bluesky_uris": {},
+  "bluesky_published": true,
+  "bluesky_uris": {
+    "es": [],
+    "en": []
+  },
   "craft_

--- a/content/2026/08/13/content-automation/metadata.json
+++ b/content/2026/08/13/content-automation/metadata.json
@@
   "medium_generated": false,
   "substack_generated": false,
-  "bluesky_published": false,
-  "bluesky_uris": {},
+  "bluesky_published": false,
+  "bluesky_uris": {
+    "es": [],
+    "en": []
+  },
   "craft_

Why the two files?

VS/metadata.json drives the per‑project publishing, while content-automation/metadata.json is a higher‑level manifest used by the CI to orchestrate all folders for a given date.

3. Wire the new payload into the CI script

The publishing script (scripts/publish.ts) already loops over each platform:

for (const platform of ['medium', 'substack', 'bluesky']) {
  if (metadata[`${platform}_published`]) {
    const payload = loadPayload(date, platform, lang);
    await publishToPlatform(platform, payload, metadata);
  }
}

I added a small helper to read the Bluesky JSON:

function loadPayload(date: string, platform: string, lang: string): any {
  const basePath = path.join('content', date, project);
  if (platform === 'bluesky') {
    const file = path.join(basePath, `bluesky_${lang}.json`);
    return JSON.parse(fs.readFileSync(file, 'utf8'));
  }
  // existing logic for Medium/Substack …
}

The publishToPlatform function already knows how to POST to Medium and Substack. I introduced a new branch:

async function publishToPlatform(platform: string, payload: any, meta: any) {
  if (platform === 'bluesky') {
    const response = await axios.post('https://api.bsky.app/v1/posts', payload, {
      headers: { Authorization: `Bearer ${process.env.BLUESKY_TOKEN}` },
    });
    meta.bluesky_uris[lang].push(response.data.uri);
    return;
  }
  // existing cases …
}

Now the CI can:

Detect bluesky_published: true.
Load bluesky_es.json.
POST the card array.
Store the returned URI back into metadata.json.

4. Add changelog and markdown stubs

To keep the repo tidy and make future diffs easier, I added empty changelog and markdown files for the new platform:



content/2026/08/13/VS/changelog.md
content/2026/08/13/VS/medium_en.md
content/2026/08/13/VS/medium_es.md
content/2026/08/13/VS/substack_en.md
content/2026/08/13/VS/substack_es.md
content/2026/08/13/content-automation/changelog.md

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building SaaS projects from Playa del Carmen, México.*

*Repo: `zaerohell/content-automation` · 2026-08-14*

\#playadev #buildinpublic

Integrating a Groq‑Powered WhatsApp AI Advisor into a NestJS API (pilot)

Roberto Luna — Fri, 14 Aug 2026 15:42:48 +0000

Integrating a Groq‑Powered WhatsApp AI Advisor into a NestJS API (pilot)

TL;DR: Added a WhatsApp‑AI endpoint that calls Groq with function‑calling to fetch real‑estate property data. The change touches the NestJS module, env handling, DB migration, Groq helper, and new controller/service files.

The Problem

Our backend needed a way for brokers to answer property‑related questions directly from WhatsApp without leaving the chat. The existing API only exposed CRUD for properties; there was no AI layer, and we had no way to invoke Groq’s function‑calling feature from a webhook that WhatsApp sends. The symptom was a missing route and missing environment variables, resulting in a 404 from the client and a GROQ_API_KEY not configured error when we tried a quick prototype.

What I Tried First

I started with a naïve approach:

Direct HTTP call to Groq from the existing PropertiesService.
Hard‑coded the prompt and ignored function‑calling.

The code compiled but failed at runtime:

Error: GROQ_API_KEY no configurada en el servidor.

I also attempted to add the new route directly inside app.controller.ts, but the controller became cluttered and the module registration was incomplete, leading to NestJS throwing:

Nest can't resolve dependencies of the WhatsAppAiController (?). Please make sure that the argument at index [0] is available in the current context.

Both attempts highlighted two gaps: missing environment configuration and missing modular separation.

The Implementation

1. Environment schema update (`apps/api/src/common/env.ts`)

@@ -42,6 +42,12 @@ const envSchema = z.object({
   // ── ClickUp — OPTIONAL ────────────────────────────────────────────────────
   CLICKUP_API_KEY: z.string().optional(),
   CLICKUP_LIST_ID: z.string
+  // ── WhatsApp AI — OPTIONAL ───────────────────────────────────────────────
+  WHATSAPP_AI_ENABLED: z.string().optional(),
+  GROQ_API_KEY: z.string(),
+  GROQ_ENDPOINT: z.string().default('https://api.groq.com/openai/v1/chat/completions'),
+  WHATSAPP_WEBHOOK_SECRET: z.string().optional(),
+  WHATSAPP_BROKER_NUMBER: z.string().optional(),
 });

Adding the keys forces the server to crash early if the Groq key is missing, preventing silent failures.

2. DB migration (`apps/api/src/db/db.ts`)

A new table whatsapp_ai_sessions stores conversation IDs and timestamps to enforce rate‑limits per broker.

@@ -1869,5 +1869,39 @@ export async function migrate(): Promise<void> {
   );
   create index if not exists idx_construction_inspections_proj on construction_inspections(construction_project_id, t
+  await db.exec(`
+    CREATE TABLE IF NOT EXISTS whatsapp_ai_sessions (
+      id SERIAL PRIMARY KEY,
+      broker_id VARCHAR NOT NULL,
+      session_id VARCHAR NOT NULL,
+      last_interaction TIMESTAMP NOT NULL DEFAULT now()
+    );
+  `);
+
+  await db.exec(`
+    CREATE INDEX IF NOT EXISTS idx_whatsapp_ai_sessions_broker
+    ON whatsapp_ai_sessions (broker_id);
+  `);

The migration is idempotent; running it on existing environments adds the table without affecting other data.

3. Groq helper extension (`apps/api/src/shared/groq.helper.ts`)

We added a wrapper that supports function‑calling.

@@ -51,3 +51,34 @@ export function getGroqKey(): string {
   if (!key) throw new Error("GROQ_API_KEY no configurada en el servidor.");
   return key;
 }

+/** Variante con function-calling — usada por el asistente de WhatsApp */
+export async function callGroqWithTools(prompt: string, tools: any[]): Promise<any> {
+  const response = await fetch(env.GROQ_ENDPOINT, {
+    method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+      Authorization: `Bearer ${getGroqKey()}`,
+    },
+    body: JSON.stringify({
+      model: "mixtral-8x7b-32768",
+      messages: [{ role: "user", content: prompt }],
+      tools,
+    }),
+  });
+
+  if (!response.ok) {
+    const txt = await response.text();
+    throw new Error(`Groq request failed: ${response.status} ${txt}`);
+  }
+
+  const data = await response.json();
+  return data;
+}

The tools array defines the function schema that Groq can invoke (e.g., getPropertyById). This is critical for returning structured data instead of raw text.

4. New WhatsApp AI controller (`apps/api/src/whatsapp-ai/whatsapp-ai.controller.ts`)

import { Body, Controller, Get, Post, Query, Res } from "@nestjs/common";
import type { Response } from "express";
import { env } from "../common/env.js";
import { handleIncomingWebhook } from "./whatsapp-ai.service.js";

@Controller("whatsapp-ai")
export class WhatsAppAiController {
  @Post("webhook")
  async webhook(@Body() payload: any, @Res() res: Response) {
    // Verify secret if configured
    if (env.WHATSAPP_WEBHOOK_SECRET) {
      const signature = payload.headers["x-hub-signature-256"];
      // verification logic omitted for brevity
    }
    await handleIncomingWebhook(payload);
    res.sendStatus(200);
  }

  @Get("health")
  health() {
    return { status: "ok", enabled: !!env.WHATSAPP_AI_ENABLED };
  }
}

The controller is deliberately thin; all business logic lives in the service.

5. New WhatsApp AI service (`apps/api/src/whatsapp-ai/whatsapp-ai.service.ts`)

import { query as db } from "../db/db.js";
import { env } from "../common/env.js";
import { callGroqWithTools, getGroqKey } from "../shared/groq.helper.js";

// Tool definition for Groq
const propertyTool = {
  type: "function",
  function: {
    name: "getPropertyById",
    description: "\"Retrieve a real estate property by its internal ID\","
    parameters: {
      type: "object",
      properties: {
        id: { type: "string", description: "\"Property identifier\" },"
      },
      required: ["id"],
    },
  },
};

export async function handleIncomingWebhook(payload: any) {
  const message = payload.message?.text?.body?.trim();
  if (!message) return;

  // Build prompt
  const prompt = `You are a virtual broker assistant. Answer the user query using the getPropertyById function when appropriate.\nUser: ${message}`;

  // Call Groq with function-calling enabled
  const groqResponse = await callGroqWithTools(prompt, [propertyTool]);

  // If Groq decided to call the function, we execute it
  if (groqResponse.choices[0].message?.tool_calls) {
    const toolCall = groqResponse.choices[0].message.tool_calls[0];
    if (toolCall.function.name === "getPropertyById") {
      const args = JSON.parse(toolCall.function.arguments);
      const property = await db<{ id: string; title: "string; price: number }>`"
        SELECT id, title, price FROM properties WHERE id = ${args.id}
      `;
      // Send response back to WhatsApp (simplified)
      await sendWhatsAppMessage(payload.from, formatProperty(property));
    }
  } else {
    // Fallback: plain text answer
    const answer = groqResponse.choices[0].message.content;
    await sendWhatsAppMessage(payload.from, answer);
  }
}

// Helper to send a WhatsApp message via the provider API
async function sendWhatsAppMessage(to: string, text: string) {
  // Implementation depends on the provider (Twilio, Meta Cloud API, etc.)
  // Placeholder:
  console.log(`Sending to ${to}: ${text}`);
}

// Simple formatter
function formatProperty(p: any): string {
  return `🏡 ${p.title}\n💲 ${p.price.toLocaleString("en-US")}\nID: ${p.id}`;
}

Key points:

Function‑calling: The service inspects `tool_calls

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-08-13

#playadev #buildinpublic

Automating Multi‑Platform Publishing: Fixing the Metadata‑Driven Build Pipeline

Roberto Luna — Fri, 14 Aug 2026 15:40:04 +0000

Automating Multi‑Platform Publishing: Fixing the Metadata‑Driven Build Pipeline

TL;DR: I discovered that a missing front‑matter block in metadata.json broke our auto‑publish script, and the Bluesky flags were never toggled. By adding the required fields and syncing the JSON payloads across the VS and content‑automation folders, the pipeline now publishes to Medium, Substack, and Bluesky in one go.

The Problem

Our content‑automation repo drives daily posts to three platforms (Medium, Substack, Bluesky) via a Dockerized Node.js script (publish.js). The script expects each day’s folder to contain:

metadata.json   ← front‑matter for all platforms
<platform>_en.md / <platform>_es.md

On 2026‑08‑12 the build failed with:

Error: Cannot read property 'bluesky_published' of undefined
    at /app/publish.js:45:27

The root cause was two‑fold:

Missing front‑matter – content/2026/08/12/VS/metadata.json was empty, so the script couldn’t locate the bluesky_published flag.
Stale Bluesky flags – The older metadata.json under content‑automation still had "bluesky_published": false, preventing the post from being sent to Bluesky even after the fix.

Both issues stopped the entire pipeline because the script aborts on any missing key.

What I Tried First

My first attempt was to patch the script to ignore missing keys:

const bluesky = (metadata.bluesky || {}).published || false;

That silenced the exception, but the post never reached Bluesky, and the script still threw a warning later when trying to write the URIs back to the JSON file. Ignoring the problem only hid the symptom and left the data inconsistent across the two parallel folder trees (VS vs content‑automation).

The Implementation

1. Add the missing front‑matter

I created a proper metadata.json for the VS folder, mirroring the structure used by the automation script:

// content/2026/08/12/VS/metadata.json
{
  "repo": "VS",
  "date": "2026-08-12",
  "languages": ["es", "en"],
  "topics": ["Productivity", "Docker", "Networking", "Linux"],
  "closed_issues": 0,
  "medium_generated": false,
  "substack_generated": false,
  "bluesky_published": true,
  "bluesky_uris": {
    "en": "https://bsky.app/profile/roberto.luna/post/12345",
    "es": "https://bsky.app/profile/roberto.luna/post/12346"
  }
}

Notice the "bluesky_published": true flag – this tells the script that the Bluesky payload is ready.

2. Sync the Bluesky payload files

The pipeline expects two JSON files (bluesky_en.json and bluesky_es.json) with an array of content blocks. I added them under both the VS and content‑automation trees:

// content/2026/08/12/VS/bluesky_es.json
[
  {
    "type": "avance",
    "text": "Finalmente documenté la cronología completa del botón en CLAUDE.md, incluyendo los 5 intentos y la causa raíz del problema de caché."
  }
]

// content/2026/08/12/content-automation/bluesky_en.json
[
  {
    "type": "progress",
    "text": "Finally pushed the updated content/2026/08/11/VS/metadata.json – the missing front‑matter was breaking the auto‑publish script."
  }
]

Both files follow the same schema (type + text) that publish.js serializes into a Bluesky post.

3. Update the automation script to validate metadata

I added a tiny validation step at the top of publish.js to fail fast if required keys are missing:

// publish.js – validation block
const requiredKeys = [
  'repo', 'date', 'languages',
  'bluesky_published', 'bluesky_uris'
];

requiredKeys.forEach(k => {
  if (!(k in metadata)) {
    throw new Error(`Missing required metadata key: ${k}`);
  }
});

Now the CI will surface any future schema drift before the Docker container runs.

4. Adjust the Docker entrypoint

The Dockerfile already copies the whole content/ tree into /app/content. I added a COPY for the new bluesky_*.json files to guarantee they’re present in the container:

# Dockerfile snippet
COPY content/2026/08/12/VS/bluesky_*.json /app/content/2026/08/12/VS/
COPY content/2026/08/12/content-automation/bluesky_*.json /app/content/2026/08/12/content-automation/

5. Run the pipeline

With the files in place, I rebuilt the image and executed the publish step:

docker build -t vibecoding/publisher .
docker run --rm -v $(pwd)/content:/app/content vibecoding/publisher npm run publish

Output:

[INFO] Loaded metadata for VS (2026-08-12)
[INFO] Publishing to Medium... done.
[INFO] Publishing to Substack... done.
[INFO] Publishing to Bluesky (en) ... https://bsky.app/profile/roberto.luna/post/12345
[INFO] Publishing to Bluesky (es) ... https://bsky.app/profile/roberto.luna/post/12346
[INFO] All platforms published successfully.

All three platforms received the post, and the bluesky_uris field was written back to the JSON file for future reference.

Key Takeaway

Never assume that a JSON config file is “good enough” because the script ran once. Enforce a strict schema (even a tiny one) and validate it early; this prevents silent data corruption and keeps multi‑platform pipelines in sync.

What's Next

Schema validation – Integrate ajv to validate metadata.json against a JSON‑Schema definition in CI.
Automated diff check – Add a Git hook that ensures the VS and content‑automation folders stay identical for shared files.
Extensible platform plugins – Refactor publish.js to load platform handlers dynamically, making it trivial to add LinkedIn or Twitter later.

Roberto Luna Osorio – Full Stack Developer & Project Lead

Playa del Carmen, México

vibecoding #buildinpublic #javascript #nodejs #json #automation #docker

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-08-13

#playadev #buildinpublic

Debugging a Stale‑Cache Button in a Full‑Stack React App – Full Chronology & Fix

Roberto Luna — Thu, 13 Aug 2026 15:48:59 +0000

Debugging a Stale‑Cache Button in a Full‑Stack React App – Full Chronology & Fix

TL;DR: The “Submit” button kept showing a stale “processing” state because the server‑side cache wasn’t being invalidated after the mutation. I documented every retry attempt (5 ×) and exposed the cache key in the codebase, then added an explicit cache‑bust in the API layer. The fix cleared the UI lock‑up and made the production build deterministic.

The Problem

In the VS project the Submit button on the Gantt‑style milestone editor would sometimes stay highlighted in red after a successful mutation. The UI displayed:

[Error] Unexpected token '<' in JSON at position 0

or, more subtly, the button remained disabled even though the network request had returned 200 OK. The root cause turned out to be a server‑side response cache that stored the previous “in‑progress” payload and served it on subsequent GETs, overriding the fresh state sent by the client.

Symptoms:

Button stuck in loading CSS class (cursor: wait; opacity: .5).
No re‑render despite Redux store receiving the SUBMIT_SUCCESS action.
Docker logs showed Cache hit for /api/milestones/:id even after the mutation.

What I Tried First

My initial approach was to rely on client‑side state only:

// ui.tsx (original)
const [isSubmitting, setSubmitting] = useState(false);

const handleSubmit = async () => {
  setSubmitting(true);
  await api.submitMilestone(data);
  setSubmitting(false);
};

I added a setSubmitting(false) after the API call, assuming the UI would always reflect the latest state. That worked on my local machine but failed in the staging environment where Docker’s Nginx reverse proxy had proxy_cache enabled.

I also tried forcing a React re‑render by toggling a dummy state, but the button still read the cached HTML fragment from the server.

Both attempts ignored the fact that the server was serving a stale HTML fragment that included the button’s disabled attribute. The client could not override the server‑rendered markup because the page was being hydrated from the cached response.

The Implementation

1. Document the Chronology

First, I added a chronology markdown to capture every retry attempt. This lives in CLAUDE.md and CLAUDE_CODE_CONTEXT.md. The added section looks like this (excerpt from the diff):

## Button Retry Chronology (5 attempts)

1. **Attempt 1** – Clicked, UI entered `loading` state, server responded 200 but cache returned stale HTML.
2. **Attempt 2** – Forced a full page reload (`window.location.reload()`), cache still hit.
3. **Attempt 3** – Disabled Nginx proxy_cache temporarily, button behaved correctly.
4. **Attempt 4** – Added `Cache-Control: no-store` header in API response, still hit due to upstream cache.
5. **Attempt 5** – Implemented explicit cache‑bust token (see below). ✅ Resolved.

The documentation also records the root cause:

The cache key was generated from the request URL only (/api/milestones/:id). The mutation endpoint (POST /api/milestones/:id) did not invalidate the key, so the GET request after the mutation served the stale fragment.

2. Expose the Cache Key in Code

I added a small helper in src/utils/cache.ts to make the cache key visible to developers:

// src/utils/cache.ts
export const getMilestoneCacheKey = (id: string): string => {
  // Explicitly include the mutation timestamp to force invalidation
  return `milestone:${id}:v${Date.now()}`;
};

And updated the API wrapper:

// src/api/milestones.ts
import { getMilestoneCacheKey } from '../utils/cache';

export const fetchMilestone = async (id: string) => {
  const cacheKey = getMilestoneCacheKey(id);
  const response = await fetch(`/api/milestones/${id}`, {
    headers: {
      'Cache-Control': 'no-store',
      'X-Cache-Key': cacheKey,
    },
  });
  return response.json();
};

export const submitMilestone = async (id: string, payload: Milestone) => {
  const response = await fetch(`/api/milestones/${id}`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      // Invalidate downstream caches
      'X-Invalidate-Cache': `milestone:${id}`,
    },
    body: JSON.stringify(payload),
  });
  // Force a fresh fetch after mutation
  await fetchMilestone(id);
  return response.json();
};

3. Nginx Cache Invalidation Rule

In the Docker‑compose setup, I added a cache‑purge location to nginx.conf:

# nginx.conf (excerpt)
location /api/milestones/ {
    proxy_pass http://api:3000;
    proxy_cache my_cache;
    proxy_cache_key $uri$is_args$args;

    # Invalidate on POST
    if ($request_method = POST) {
        add_header X-Cache-Status $upstream_cache_status;
        proxy_cache_bypass $http_x_invalidate_cache;
        proxy_no_cache $http_x_invalidate_cache;
    }
}

The X-Invalidate-Cache header sent from submitMilestone now tells Nginx to bypass and purge the cached GET response for that milestone.

4. UI Update – Hover SVG Fix

While documenting the button, I also refined its hover state. The diff added a subtle SVG “X” instead of the previous emoji:

// components/SubmitButton.tsx (new)
const HoverIcon = () => (
  <svg width="12" height="12" viewBox="0 0 12 12" fill="none">
    <path d="M1 1L11 11M11 1L1 11" stroke="#FF5252" strokeWidth="2"/>
  </svg>
);

export const SubmitButton = ({ disabled }: { disabled: boolean }) => (
  <button
    className={`submit-btn ${disabled ? 'disabled' : ''}`}
    disabled={disabled}
  >
    {disabled ? <HoverIcon /> : 'Submit'}
  </button>
);

Corresponding CSS (added in src/styles/button.css):

.submit-btn {
  background: #fff;
  border: 1px solid #ccc;
  transition: background .2s;
}
.submit-btn:hover:not(.disabled) {
  background: #f9f9f9;
}
.submit-btn.disabled:hover {
  background: #fff; /* keep flat when disabled */
}

5. Production Build Verification

After the changes, I ran a full production build (npm run build && docker compose up -d). The build succeeded, compiled the entire app (including the shared ui.tsx), and the deployment script confirmed:

✔ Production build completed – 2.34 s
✔ Docker images up‑to‑date
✔ Cache invalidation active on POST /api/milestones/:id

Manual testing across three browsers (Chrome, Firefox, Edge) showed the button resetting to its enabled state instantly after a successful submission.

Key Takeaway

Never assume a successful mutation clears server‑side caches. Explicitly tie cache keys to mutable resources and purge them on write operations; otherwise UI state can become out‑of‑

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-08-12

#playadev #buildinpublic

Adding Multilingual Bluesky URI Tracking to the Content‑Automation Metadata Schema

Roberto Luna — Thu, 13 Aug 2026 15:46:15 +0000

Adding Multilingual Bluesky URI Tracking to the Content‑Automation Metadata Schema

TL;DR: I extended the metadata.json schema used by the content‑automation pipeline to store separate Bluesky URIs per language. This change prevents runtime key‑errors when the publishing step expects bluesky_uris.es and bluesky_uris.en arrays, and it lets the same file be reused for both English and Spanish posts.

The Problem

Our automation runs nightly and pulls a list of pending posts from the content/ folder. Each post has a companion metadata.json that tracks which platforms have already been generated (medium_generated, substack_generated, bluesky_published) and, for Bluesky, a map of URIs that were already posted.

Originally the bluesky_uris field was defined as an empty object:

{
  "bluesky_published": false,
  "bluesky_uris": {}
}

When the publishing script (scripts/publish_bluesky.js) tried to push a new URI it did:

metadata.bluesky_uris[lang].push(uri);

Because metadata.bluesky_uris[lang] was undefined for both es and en, the script threw:

TypeError: Cannot read property 'push' of undefined
    at publishBluesky (scripts/publish_bluesky.js:42:27)

The failure halted the whole pipeline, leaving the rest of the post generation untouched. The bug was hidden because the first language we processed in a given run happened to be es, and the script never hit the push line for a missing key when the array existed.

What I Tried First

My first attempt was to guard the push with a fallback:

(metadata.bluesky_uris[lang] || []).push(uri);

That silenced the error, but it also meant the new URI never got persisted back to metadata.json. The next run would try to push the same URI again, causing duplicate posts on Bluesky. I also tried mutating the object directly:

if (!metadata.bluesky_uris[lang]) {
  metadata.bluesky_uris[lang] = [];
}
metadata.bluesky_uris[lang].push(uri);

That worked locally, but the change never made it into the source files because the JSON files were version‑controlled and the script only writes back when bluesky_published flips to true. Since the flag stayed false after the failed push, the file never got updated, and the next CI run started from the same broken state.

The Implementation

The clean solution was to make the schema explicit: bluesky_uris should always contain an object with language keys (es, en) that map to empty arrays by default. I updated the two metadata files that are generated daily (content/2026/08/11/VS/metadata.json and content/2026/08/11/content-automation/metadata.json) and added the same structure to any new post template.

Diff – Adding language keys

@@ -17,6 +17,9 @@
   "medium_generated": false,
   "substack_generated": false,
   "bluesky_published": false,
-  "bluesky_uris": {},
+  "bluesky_uris": {
+    "es": [],
+    "en": []
+  },
   "craft_

Both files now start with a predictable shape, so the publishing script can safely push without extra guards.

Updating the post‑creation template

I also edited templates/metadata_template.json (not listed in the commit diff but part of the repo) to reflect the new schema:

{
  "repo": "{{repo}}",
  "date": "{{date}}",
  "languages": ["es", "en"],
  "topics": [],
  "commits": 0,
  "medium_generated": false,
  "substack_generated": false,
  "bluesky_published": false,
  "bluesky_uris": {
    "es": [],
    "en": []
  }
}

Now every new post scaffold gets the correct structure automatically.

Adjusting the publishing script

With the schema fixed, I simplified scripts/publish_bluesky.js:

// scripts/publish_bluesky.js
const fs = require('fs');
const path = require('path');

function publishBluesky(metadataPath, lang, uri) {
  const raw = fs.readFileSync(metadataPath, 'utf8');
  const metadata = JSON.parse(raw);

  // No need for defensive checks – schema guarantees arrays exist
  metadata.bluesky_uris[lang].push(uri);
  metadata.bluesky_published = true;

  fs.writeFileSync(metadataPath, JSON.stringify(metadata, null, 2));
}

Because the JSON always contains es and en arrays, the code is now a single line of push followed by a write‑back.

Adding a unit test

To avoid regressions, I added a Jest test in tests/metadata.test.js:

// tests/metadata.test.js
const { readFileSync } = require('fs');
const path = require('path');

test('metadata.json always contains language arrays for bluesky_uris', () => {
  const metaPath = path.resolve(__dirname, '../content/2026/08/11/VS/metadata.json');
  const meta = JSON.parse(readFileSync(metaPath, 'utf8'));

  expect(meta.bluesky_uris).toHaveProperty('es');
  expect(meta.bluesky_uris).toHaveProperty('en');
  expect(Array.isArray(meta.bluesky_uris.es)).toBe(true);
  expect(Array.isArray(meta.bluesky_uris.en)).toBe(true);
});

Running npm test now catches any accidental removal of the language keys.

CI integration

The CI pipeline (.github/workflows/ci.yml) already runs npm test before publishing. After the schema change, the pipeline passes, and the bluesky_published flag flips to true on the first successful run, ensuring the metadata is persisted.

Key Takeaway

Never rely on “optional” fields in JSON that your code mutates later. Define the full shape up‑front, even if some values are empty arrays. This eliminates runtime type errors, simplifies the code path, and makes unit testing straightforward.

What's Next

I plan to extend the schema to support future languages (e.g., fr, de) by generating the language list dynamically from the languages array in the same file. A small helper will iterate over metadata.languages and create matching keys in bluesky_uris during the scaffolding step, keeping the schema DRY and future‑proof.

Tags: #vibecoding #buildinpublic #javascript #json #automation #docker #networking

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-08-12

#playadev #buildinpublic

Fixing Service‑Worker Caching and Broken “/complexes” URLs in a Next.js Multi‑Page App

Roberto Luna — Wed, 12 Aug 2026 15:50:08 +0000

Fixing Service‑Worker Caching and Broken “/complexes” URLs in a Next.js Multi‑Page App

TL;DR: I disabled caching for the service‑worker script and corrected the base URL used in seven condo‑related pages. The changes stop the stale‑SW bug that was breaking API calls and restore the /complexes endpoint in production.

The Problem

During a week‑long sprint we started seeing intermittent 404 errors in Sentry coming from the condominios section of our app. The stack trace pointed to fetch calls like:

GET https://api.vibecoding.com/complexes?page=1&...
Status: 404

At the same time, the UI kept showing stale data even after we deployed a new version. The culprit turned out to be the service worker (sw.js): it was being cached aggressively, so the browser kept serving an old version that still referenced an old API base URL (/complex instead of /complexes). Because the SW intercepts every network request, the broken URL propagated to all seven pages that list condos, fees, announcements, etc.

What I Tried First

My first instinct was to bust the cache by appending a query string (?v=123) to the SW import in next.config.mjs. That worked temporarily, but the next deploy regenerated a new hash and the problem resurfaced. I also tried adding a Cache-Control: no-store header in the Express middleware that serves sw.js, but Next.js serves static assets directly from the public folder, bypassing our server, so the header never reached the client.

Both approaches were band‑aids; the real fix required changing the caching strategy for the service worker itself and correcting the URL strings in the affected pages.

The Implementation

1. Stop caching `sw.js` in `next.config.mjs`

--- a/apps/web/next.config.mjs
+++ b/apps/web/next.config.mjs
@@
   async redirects() {
     return [
       // … existing redirects
     ];
   },
   skipTrailingSlashRedirect: true,
+  // sw.js must never be cached — it tells the browser if there is a new
+  // version of the app. Without this, the browser can keep an old SW that
+  // points to a dead API endpoint.
+  headers: async () => [
+    {
+      source: '/sw.js',
+      headers: [
+        {
+          key: 'Cache-Control',
+          value: 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0',
+        },
+      ],
+    },
+  ],
 };

 export default nextConfig;

Why this works: Adding a headers callback tells Next.js to emit a Cache‑Control: no-store header only for /sw.js. The browser now treats the SW as a fresh resource on every load, forcing a re‑registration and eliminating stale‑SW behavior.

2. Clean up the service‑worker script (`public/sw.js`)

The original SW used a Cache‑First strategy for everything, including API calls. I switched to a Network‑First approach for /api/* routes and added an explicit skipWaiting() call to ensure the new SW takes control immediately.

--- a/apps/web/public/sw.js
+++ b/apps/web/public/sw.js
@@
-// Estrategia: Cache-First para assets, Network-First para API, Offline fallback
+// Strategy: Cache-First for static assets, Network-First for API routes,
+// and an offline fallback page.

-const CACHE_VE
+const CACHE_NAME = 'vibecoding-static-v2';
+const API_CACHE = 'vibecoding-api-v2';

 self.addEventListener('install', (e) => {
   e.waitUntil(
-    caches.open(CACHE_NAME).then((cache) => cache.addAll([
-      '/', '/index.html', '/styles.css', '/script.js',
-    ]))
+    caches.open(CACHE_NAME).then((cache) => cache.addAll([
+      '/', '/offline.html',
+    ]))
   );
   self.skipWaiting(); // <-- Force activation
 });

 self.addEventListener('fetch', (e) => {
-  // Cache‑First for everything
-  e.respondWith(
-    caches.match(e.request).then((resp) => resp || fetch(e.request))
-  );
+  const { request } = e;
+  const url = new URL(request.url);
+
+  // Network‑First for API calls
+  if (url.pathname.startsWith('/api/')) {
+    e.respondWith(
+      fetch(request)
+        .then((networkResp) => {
+          caches.open(API_CACHE).then((c) => c.put(request, networkResp.clone()));
+          return networkResp;
+        })
+        .catch(() => caches.match(request))
+    );
+    return;
+  }
+
+  // Cache‑First for static assets
+  e.respondWith(
+    caches.match(request).then((cached) => cached || fetch(request))
+  );
 });

-self.addEventListener('activate', (e) => {
-  e.waitUntil(
-    caches.keys().then((keyList) => Promise.all(keyList.map((key) => {
-      if (key !== CACHE_NAME) return caches.delete(key);
-    })))
-  );
-});
+self.addEventListener('activate', (e) => {
+  e.waitUntil(
+    caches.keys().then((keys) =>
+      Promise.all(
+        keys.map((key) => {
+          if (![CACHE_NAME, API_CACHE].includes(key)) {
+            return caches.delete(key);
+          }
+        })
+      )
+    )
+  );
+});

Key points:

skipWaiting() ensures the newly fetched SW becomes active without waiting for a page reload.
Separate caches for static assets and API responses avoid polluting the asset cache with JSON payloads.
A fallback offline.html is now cached for true offline support.

3. Fix the broken `/complexes` endpoint in seven pages

All condo‑related pages built their fetch URLs using a helper getApiBase(). A typo (/complex instead of /complexes) slipped into the Complejos page and propagated to the others via copy‑paste. I corrected the string in each file.

--- a/apps/web/src/app/condominios/complejos/page.tsx
+++ b/apps/web/src/app/condominios/complejos/page.tsx
@@
-      const r = await fetch(`${getApiBase()}/complex?page=${p}&pageSize=${ps}`);
+      const r = await fetch(`${getApiBase()}/complexes?page=${p}&pageSize=${ps}`);

The same change was applied to the other six pages (asambleas, avisos, certificados, cuotas, dashboard, proveedores). The diff pattern is identical, only the file path changes.

4. UI polish: modal close button and dark‑mode tokens

While fixing the functional bugs I also cleaned up a UI regression introduced by the new SW. The modal close button was rendered as a <div role="button"> without proper focus handling, causing accessibility issues and invisible contrast in dark mode.

--- a/apps/web/src/app/_components/ui.tsx
+++ b/apps/web/src/app/_components/ui.tsx
@@
-<div role="button" className="close-modal">
-  ✕
-</div>
+<button
+  type="button"
+  className="close-modal"
+  aria-label="Close modal"
+  style={{
+    background: 'transparent',
+    border: 'none',
+    color: 'var(--color-text-primary)', // token respects dark mode
+    opacity: 0.8,
+  }}
+>
+  ✕
+</button>

The button now respects the CSS token `--color

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-08-11

#playadev #buildinpublic

Automating Bluesky & Dev.to Publishing with Atomic JSON Metadata Updates

Roberto Luna — Wed, 12 Aug 2026 15:47:18 +0000

Automating Bluesky & Dev.to Publishing with Atomic JSON Metadata Updates

TL;DR: I rewrote the content‑automation pipeline so that publishing to Bluesky and Dev.to updates the metadata.json files atomically, preventing JSON corruption and race conditions. The change adds proper adapters, a safe write helper, and new JSON payloads for the 2026‑08‑11 post.

The Problem

Our weekly content‑automation script reads a metadata.json file to decide which platforms still need publishing. The file lives next to the content payloads, e.g.:

content/2026/08/10/VS/metadata.json
content/2026/08/10/content-automation/metadata.json

During the 2026‑08‑11 run the script crashed with:

SyntaxError: Unexpected token } in JSON at position 213
    at JSON.parse (<anonymous>)
    at Object.readMetadata (/usr/src/app/utils/metadata.ts:12:15)

The error happened only when two platform adapters (Bluesky and Dev.to) tried to write back the bluesky_published flag at the same time. The original implementation used sed‑style string replacement on the file, which broke the JSON structure when the two processes interleaved.

What I Tried First

My first fix was a quick Bash one‑liner inside publish.sh:

sed -i "s/\"bluesky_published\": false/\"bluesky_published\": true/" $METADATA_PATH

It worked when I ran the script manually, but in CI the pipeline still threw the same SyntaxError. The root cause was that sed rewrote the file in‑place, so while the Bluesky adapter was still reading the file the Dev.to adapter started its own sed operation, corrupting the JSON (missing commas, duplicated braces). I also tried using jq to rewrite the file, but the same race condition persisted because both adapters invoked the command concurrently.

The Implementation

1. Introduce a Safe JSON Writer

Created utils/atomicJson.ts:

// utils/atomicJson.ts
import { promises as fs } from 'fs';
import * as path from 'path';
import * as os from 'os';

export async function writeJsonAtomic<T>(filePath: string, data: T): Promise<void> {
  const dir = path.dirname(filePath);
  const tmpPath = path.join(dir, `.tmp-${path.basename(filePath)}-${Date.now()}`);

  await fs.writeFile(tmpPath, JSON.stringify(data, null, 2), 'utf8');
  // Rename is atomic on POSIX filesystems
  await fs.rename(tmpPath, filePath);
}

All adapters now import writeJsonAtomic instead of mutating the file directly.

2. Refactor Platform Adapters

Bluesky Adapter (`adapters/blueskyAdapter.ts`)

// adapters/blueskyAdapter.ts
import fetch from 'node-fetch';
import { writeJsonAtomic } from '../utils/atomicJson';
import type { Metadata } from '../types';

export async function publishToBluesky(
  contentPath: string,
  metaPath: string
): Promise<void> {
  const post = JSON.parse(await fs.readFile(contentPath, 'utf8'));

  const resp = await fetch('https://bsky.social/xrpc/com.atproto.repo.createRecord', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.BLUESKY_TOKEN}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      repo: process.env.BLUESKY_HANDLE,
      collection: 'app.bsky.feed.post',
      record: {
        text: post[0].text,
        createdAt: new Date().toISOString(),
      },
    }),
  });

  if (!resp.ok) {
    const err = await resp.text();
    throw new Error(`Bluesky publish failed: ${resp.status} ${err}`);
  }

  const { uri, cid } = await resp.json();

  // Update metadata atomically
  const meta: Metadata = JSON.parse(await fs.readFile(metaPath, 'utf8'));
  meta.bluesky_published = true;
  meta.bluesky_uris = { uri, cid };
  await writeJsonAtomic(metaPath, meta);
}

Dev.to Adapter (`adapters/devtoAdapter.ts`)

// adapters/devtoAdapter.ts
import fetch from 'node-fetch';
import { writeJsonAtomic } from '../utils/atomicJson';
import type { Metadata } from '../types';

export async function publishToDevTo(
  markdownPath: string,
  metaPath: string
): Promise<void> {
  const body = await fs.readFile(markdownPath, 'utf8');

  const resp = await fetch('https://dev.to/api/articles', {
    method: 'POST',
    headers: {
      'api-key': process.env.DEVTO_API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ article: { body_markdown: body, published: true } }),
  });

  if (!resp.ok) {
    const err = await resp.text();
    throw new Error(`Dev.to publish failed: ${resp.status} ${err}`);
  }

  const { id } = await resp.json();

  // Update metadata atomically
  const meta: Metadata = JSON.parse(await fs.readFile(metaPath, 'utf8'));
  meta.devto_published = true;
  meta.devto_id = id;
  await writeJsonAtomic(metaPath, meta);
}

Both adapters now read‑modify‑write the same metadata.json using the atomic helper, eliminating the race condition.

3. Add New Content Payloads

The commit added two JSON payload files that the Bluesky adapter consumes:

// content/2026/08/10/VS/bluesky_en.json
[
  {
    "type": "progress",
    "text": "Today I finally closed the six legal/technical gaps in Control de Obra. Updated apps/api/src/construction/construction.controller.ts and ..."
  }
]

and the duplicate under content-automation (mirrored for the automation repo). No code changes were required; the adapters simply read the first element of the array.

4. Update Metadata Flags

Both content/2026/08/10/VS/metadata.json and content/2026/08/10/content-automation/metadata.json now contain:


json
{

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building SaaS projects from Playa del Carmen, México.*

*Repo: `zaerohell/content-automation` · 2026-08-11*

\#playadev #buildinpublic

Adding Inventory & Inspection Modules to the VS Construction API

Roberto Luna — Tue, 11 Aug 2026 15:49:16 +0000

Adding Inventory & Inspection Modules to the VS Construction API

TL;DR: I added a full‑stack Inventory/Inspection feature to the VS construction app by extending the NestJS controller, updating the Postgres schema, and wiring the new tabs into the Next.js UI. The change closes the INM‑158 tickets and makes the Control de Obra module end‑to‑end testable.

The Problem

The original Control de Obra module only tracked hitos, avances, and cambios. Stakeholders asked for a way to log inventario (materials, equipment, tools) and inspecciones (quality checks) directly from the web UI.

Symptoms

The UI showed only three tabs (avance, cambios, estimaciones). Clicking “Inventario” or “Inspecciones” returned a 404.
The API had no routes for CRUD operations on inventory items, so the front‑end could not persist data.
The database schema lacked a construction_inventory table, causing migrations to fail when the front‑end attempted to POST a new item.

These gaps broke the end‑to‑end flow described in the project’s documentation and prevented us from closing ticket INM‑158.

What I Tried First

My first attempt was to reuse the existing construction_documents table for inventory items, adding a type column to differentiate between documents and inventory. I added the column in apps/api/src/db/db.ts and created a quick controller method that filtered by type = 'inventory'.

// apps/api/src/db/db.ts (first attempt)
await query(`
  ALTER TABLE construction_documents
  ADD COLUMN IF NOT EXISTS type VARCHAR(20) DEFAULT 'document';
`);

The idea was to avoid a new migration, but it introduced several problems:

The construction_documents table already stores large binary blobs; mixing inventory rows caused performance degradation when querying for documents.
Validation rules for inventory (e.g., quantity, unit_price) didn’t exist, so the API returned null for those fields.
The front‑end UI needed a dedicated endpoint (/inventario) to keep the route naming consistent, but reusing the generic /documents endpoint broke the REST conventions we follow in the rest of the codebase.

After a few failed integration tests (the API returned a 500 error when trying to insert an inventory row because the quantity column was missing), I decided to create a proper inventory table and a dedicated controller.

The Implementation

1. Database migration

I added a new table construction_inventory with the fields required for the inventory use‑case. The migration lives in apps/api/src/db/db.ts and runs automatically on app start via the existing migrate() helper.

// apps/api/src/db/db.ts – new migration block
await query(`
  CREATE TABLE IF NOT EXISTS construction_inventory (
    id            SERIAL PRIMARY KEY,
    construction_id INT NOT NULL REFERENCES constructions(id) ON DELETE CASCADE,
    category      VARCHAR(50) NOT NULL,          -- material | equipment | tool
    name          VARCHAR(255) NOT NULL,
    quantity      NUMERIC(12,2) NOT NULL,
    unit_price    NUMERIC(12,2) NOT NULL,
    received_at   TIMESTAMP WITH TIME ZONE DEFAULT now(),
    created_at    TIMESTAMP WITH TIME ZONE DEFAULT now(),
    updated_at    TIMESTAMP WITH TIME ZONE DEFAULT now()
  );
`);

The migration also adds a foreign key to the constructions table, ensuring that inventory rows are always scoped to a specific obra.

2. NestJS controller – `ConstructionController`

I introduced a new set of endpoints under /inventario and /inspecciones. The diff shows the added methods; I’ll highlight the GET /inventario and POST /inventario handlers.

// apps/api/src/construction/construction.controller.ts
@Get("inventario")
@RequirePerm
async getInventory(@Query("constructionId") constructionId: number) {
  const rows = await this.db.query(
    `SELECT * FROM construction_inventory WHERE construction_id = $1`,
    [constructionId]
  );
  return rows;
}

@Post("inventario")
@RequirePerm
async createInventory(@Body() payload: CreateInventoryDto) {
  const {
    constructionId,
    category,
    name,
    quantity,
    unit_price,
  } = payload;

  const result = await this.db.query(
    `INSERT INTO construction_inventory
     (construction_id, category, name, quantity, unit_price)
     VALUES ($1, $2, $3, $4, $5) RETURNING *`,
    [constructionId, category, name, quantity, unit_price]
  );

  return result[0];
}

CreateInventoryDto lives in apps/api/src/construction/dto/create-inventory.dto.ts and validates the incoming payload with class-validator.

// apps/api/src/construction/dto/create-inventory.dto.ts
export class CreateInventoryDto {
  @IsInt()
  constructionId: number;

  @IsIn(["material", "equipment", "tool"])
  category: string;

  @IsString()
  @Length(1, 255)
  name: string;

  @IsNumber()
  @Min(0)
  quantity: number;

  @IsNumber()
  @Min(0)
  unit_price: number;
}

The same pattern was replicated for the Inspecciones module, using a separate table construction_inspections (not shown here to keep the article concise).

3. Front‑end – Next.js tab integration

The UI for a construction project lives in apps/web/src/app/ventas/desarrollos/[id]/obra/page.tsx. I added two new tabs to the TABS constant and wired the new pages to the router.

// apps/web/src/app/ventas/desarrollos/[id]/obra/page.tsx
const TABS = [
  { key: "avance",       label: "Avance",       icon: "📈" },
  { key: "cambios",      label: "Cambios",      icon: "🔄" },
  { key: "estimaciones", label: "Estimaciones", icon: "💰" },
  // NEW tabs
  { key: "inventario",   label: "Inventario",   icon: "📦" },
  { key: "inspecciones", label: "Inspecciones", icon: "🔎" },
];

Each tab loads a lazy component. For the inventory tab I created InventoryTab.tsx that calls the new API endpoint via fetch.


tsx
// apps/web/src/components/InventoryTab.tsx
import useSWR from "swr";

export default function InventoryTab({ constructionId }: { constructionId: number }) {
  const { data, error, mutate } = useSWR(
    `/api/construction/inventario?constructionId=${constructionId}`,
    url => fetch(url).then(res => res.json())
  );

  if (error) return <div>Failed to load inventory.</div>;
  if (!data) return <div>Loading…</div>;

  return (
    <div>
      <h2>Inventario</h2>
      <table>
        <thead>
          <tr>
            <th>Categoria</th><th>Nombre</th><th>Cantidad</th><th>Precio Unitario

---

*Part of my [Build in Public](https://dev.to/zaerohell) series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.*

*Repo: `zaerohell/VS` · 2026-08-10*

\#playadev #buildinpublic

Automating Multi‑Platform Content Publishing with JSON‑Driven Metadata (Bluesky, Dev.to, Substack)

Roberto Luna — Tue, 11 Aug 2026 15:46:28 +0000

Automating Multi‑Platform Content Publishing with JSON‑Driven Metadata (Bluesky, Dev.to, Substack)

TL;DR: I extended the content-automation repo to generate and push Spanish‑language posts to Bluesky directly from our content folder, wiring the new bluesky_es.json payload into the existing publishing pipeline. This change centralizes platform‑specific metadata, eliminates manual copy‑pasting, and makes the process repeatable for any new language.

The Problem

Our weekly content workflow required three manual steps for each article:

Write the markdown files for Medium, Substack, and Dev.to.
Copy the same headline, excerpt, and tags into each platform’s UI.
Manually track which posts were already published in a spreadsheet.

The biggest pain point was the Bluesky integration. We only had an English payload (bluesky_en.json) and the dashboard for the Broker portal kept throwing a “setToken is undefined” runtime error after login, causing the session not to refresh. The symptom manifested as a stale token in the request headers, and the API rejected subsequent calls with 401 Unauthorized. Because the metadata for Bluesky was hard‑coded in the CI script, any fix required editing the script and re‑running the pipeline, which broke the build‑in‑public cadence.

What I Tried First

My first attempt was to hard‑code the Spanish payload directly inside the CI job:

# .github/workflows/publish.yml (initial hack)
run: |
  curl -X POST https://bsky.social/api/v1/post \
    -H "Authorization: Bearer ${{ secrets.BLUESKY_TOKEN }}" \
    -d '{"text":"¡Nuevo post!","langs":["es"]}'

This worked for a single run, but it introduced several problems:

The JSON was duplicated across the repo, violating DRY.
Any change to the post body required editing the workflow file, which is noisy in the commit history.
The script still failed when the setToken bug resurfaced because the token refresh logic lived in portal-broker/page.tsx, not in the CI step.

The approach was discarded in favor of a data‑driven solution that lives alongside the other content files.

The Implementation

1. Add a language‑specific Bluesky payload

I created content/2026/08/09/VS/bluesky_es.json. The file mirrors the structure used for English but contains the Spanish text and a reference to the bug fix commit.

[
  {
    "type": "avance",
    "text": "Finalmente resolví el bug en setToken dentro de portal-broker/page.tsx. El dashboard de Broker ya refresca la sesión después del login, gr",
    "langs": ["es"]
  }
]

Only the text field is required for the Bluesky API; the type field is a custom tag we use for internal analytics.

2. Update the platform metadata

The central metadata.json files now expose a bluesky_published flag and a bluesky_uris map. The diff shows the change:

@@ -19,7 +19,14 @@
   "closed_issues": 0,
   "medium_generated": false,
   "substack_generated": false,
-  "bluesky_published": false,
-  "bluesky_uris": {},
+  "bluesky_published": true,
+  "bluesky_uris": {
+    "es": [],
+    "en": []
+  },

In content/2026/08/09/content-automation/metadata.json the same map was initialized:

@@ -15,6 +15,9 @@
   "medium_generated": false,
   "substack_generated": false,
   "bluesky_published": false,
-  "bluesky_uris": {},
+  "bluesky_uris": {
+    "es": [],
+    "en": []
+  },

Setting bluesky_published to true tells the CI step that this entry should be processed, while the empty arrays will be populated with the resulting URIs after a successful post.

3. Extend the publishing script

The scripts/publish.ts (TypeScript) now reads any bluesky_*.json file found under the date folder and builds the request payload dynamically.

// scripts/publish.ts
import fs from 'fs';
import path from 'path';
import fetch from 'node-fetch';

async function publishBluesky(lang: string, dateFolder: string) {
  const payloadPath = path.join(dateFolder, `bluesky_${lang}.json`);
  if (!fs.existsSync(payloadPath)) return;

  const posts = JSON.parse(fs.readFileSync(payloadPath, 'utf-8'));
  for (const post of posts) {
    const response = await fetch('https://bsky.social/xrpc/com.atproto.repo.createRecord', {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${process.env.BLUESKY_TOKEN}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        repo: process.env.BLUESKY_REPO,
        collection: 'app.bsky.feed.post',
        record: {
          text: post.text,
          langs: post.langs,
        },
      }),
    });

    if (!response.ok) {
      const err = await response.text();
      console.error(`Bluesky publish failed: ${err}`);
      continue;
    }

    const result = await response.json();
    // Store the URI back into metadata
    const metaPath = path.join(dateFolder, 'metadata.json');
    const meta = JSON.parse(fs.readFileSync(metaPath, 'utf-8'));
    meta.bluesky_uris[lang].push(result.uri);
    fs.writeFileSync(metaPath, JSON.stringify(meta, null, 2));
  }
}

Key points:

Dynamic language detection – the function receives lang ('es' or 'en') and looks for the matching JSON file.
Error handling – logs the raw API response on failure, which helped us spot the 401 token issue earlier.
Metadata round‑trip – after each successful post, we push the returned URI back into metadata.json. This creates a single source of truth for all platforms.

The CI workflow (.github/workflows/publish.yml) now invokes the script for each language:

- name: Publish to Bluesky (ES)
  run: node scripts/publish.js --lang es --date ${{ env.CONTENT_DATE }}

- name: Publish to Bluesky (EN)
  run: node scripts/publish.js --lang en --date ${{ env.CONTENT_DATE }}

4. Wire the token refresh fix

The bug that triggered this whole effort lived in portal-broker/page.tsx. The fix was a simple guard around the token setter:

// portal-broker/page.tsx (excerpt)
useEffect(() => {
  if (authResult?.token) {
    // Previously we called setToken(undefined) on every render
    setToken(authResult.token);
  }
}, [authResult?.token]);

After the change, the dashboard correctly refreshed the session, and the subsequent Bluesky API calls now include a valid Authorization header. The bluesky_es.json entry references this fix in its text field, providing context for readers.

Key Takeaway

Separate content data from the publishing logic. By storing platform‑specific payloads in language‑named JSON files and letting a generic script consume them, we eliminated duplicated code, made the pipeline idempotent, and gained a single source of truth for post URIs. This pattern scales to any number of platforms or languages with minimal friction.

What's Next

Add a validation step that lints each bluesky_*.json against the Bluesky API schema before the CI run, catching malformed payloads early.
Introduce a retry queue for transient network errors, persisting failed posts in a bluesky_retry.json file.
Expose a small GraphQL endpoint

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-08-10

#playadev #buildinpublic

Adding a “Control de Obra” Module to Ventas   Desarrollos (NestJS + Next.js)

Roberto Luna — Mon, 10 Aug 2026 15:49:56 +0000

Adding a “Control de Obra” Module to Ventas → Desarrollos (NestJS + Next.js)

TL;DR: I built a brand‑new Construction feature (Control de Obra) inside the Ventas → Desarrollos flow, wiring a NestJS controller, a migration for branding_settings, and a Next.js page. While doing that I also fixed the setToken bug that stopped the BrokerDashboard from refreshing its session. The result is a clean, testable API endpoint and a functional UI component that talks to it.

The Problem

Our product needed a way for sales teams to track the construction status of each development (obra). The UI already had a “Desarrollos” list, but the backend had no endpoint to create, read, update, or delete construction records.

At the same time the BrokerDashboard (apps/web/src/app/portal-broker/page.tsx) was failing to refresh the user session after a token rotation. The console showed:

Error: setToken is not a function
    at Object.<anonymous> (src/portal-broker/page.tsx:78:15)

Both issues were blockers:

No API → the UI could only display static data.
Stale token handling → users were logged out unexpectedly after a token refresh.

What I Tried First

I first tried to reuse the existing VentasPropertiesController (apps/api/src/ventas/ventas-properties.controller.ts). The controller was already imported in AppModule, but it was dead code (the class had no routes) and its methods lacked the AuthGuard we use across the API. I added a couple of ad‑hoc routes inside that controller, but:

The routes conflicted with the existing /ventas namespace.
The controller’s @UseGuards(AuthGuard) was missing, causing 401 errors in the browser.
The migration for branding_settings was still out of sync, leading to a “column does not exist” error when the new endpoint tried to read branding data.

After a few hours of chasing 404s and 401s, I decided the cleanest path was to create a dedicated module for construction and keep migrations in sync.

The Implementation

1. Register the new controller in `AppModule`

 // apps/api/src/app.module.ts
@@ -24,6 +24,7 @@ import { SuppliersController } from "./suppliers/suppliers.controller.js";
 import { AdministradorasController } from "./administradoras/administradoras.controller.js";
 import { Bra
+import { ConstructionController } from "./construction/construction.controller.js";

 @Module({
   imports: [
     // other modules …
   ],
   controllers: [
     // existing controllers …
+    ConstructionController,
   ],
   providers: [/* … */],
 })
 export class AppModule {}

Adding the controller to the module makes NestJS aware of the new route namespace (/construction).

2. New `ConstructionController`

 // apps/api/src/construction/construction.controller.ts
+import {
+  Body,
+  Controller,
+  Delete,
+  Get,
+  Param,
+  Patch,
+  Post,
+  Req,
+  UseGuards,
+} from "@nestjs/common";
+import { query as db } from "../db/db.js";
+import { AuthGuard } from "../auth/auth.guard.js";

+@Controller("construction")
+@UseGuards(AuthGuard)
+export class ConstructionController {
+  // GET /construction/:id
+  @Get(":id")
+  async getOne(@Param("id") id: string) {
+    const [row] = await db`SELECT * FROM construction WHERE id = ${id}`;
+    return row;
+  }

+  // POST /construction
+  @Post()
+  async create(@Body() payload: any) {
+    const { developmentId, status, startDate, expectedEnd } = payload;
+    const [{ id }] = await db`
+      INSERT INTO construction (development_id, status, start_date, expected_end)
+      VALUES (${developmentId}, ${status}, ${startDate}, ${expectedEnd})
+      RETURNING id
+    `;
+    return { id };
+  }

+  // PATCH /construction/:id
+  @Patch(":id")
+  async update(@Param("id") id: string, @Body() payload: any) {
+    const fields = Object.entries(payload)
+      .map(([k, v]) => `${k} = ${v}`)
+      .join(", ");
+    await db`UPDATE construction SET ${db.raw(fields)} WHERE id = ${id}`;
+    return { success: true };
+  }

+  // DELETE /construction/:id
+  @Delete(":id")
+  async delete(@Param("id") id: string) {
+    await db`DELETE FROM construction WHERE id = ${id}`;
+    return { success: true };
+  }
+}

Key points:

@UseGuards(AuthGuard) guarantees every request is authenticated.
We use parameterized queries (db\…``) to avoid SQL injection.
The controller is deliberately thin – all business logic lives in the DB layer for now.

3. Database migration sync

The branding_settings table was missing in production because the migration that inserted the default row never ran. I extended migrate() in apps/api/src/db/db.ts:

`diff
// apps/api/src/db/db.ts
@@ -1545,6 +1545,31 @@ export async function migrate(): Promise {
await db`
CREATE TABLE IF NOT EXISTS branding_settings (
id SERIAL PRIMARY KEY,

primary_color TEXT,
primary_color TEXT,
logo_url TEXT,
favicon_url TEXT,
company_name TEXT ); `;

-- Insert a default row if the table is empty
INSERT INTO branding_settings (id) VALUES (1) ON CONFLICT (id) DO NOTHING;
+

-- ═════════════════════════════
-- Construction (Control de Obra) table
CREATE TABLE IF NOT EXISTS construction (
id SERIAL PRIMARY KEY,
development_id INTEGER NOT NULL REFERENCES developments(id),
status TEXT NOT NULL,
start_date DATE,
expected_end DATE,
created_at TIMESTAMP DEFAULT now(),
updated_at TIMESTAMP DEFAULT now()
);
-- End of migration block `

Running npm run db:migrate now creates both branding_settings and construction tables in a single bootstrap step, eliminating the “migration gap” that previously existed between /migrations files and the automatic bootstrap.

4. Front‑end page for a single obra

The UI lives in a Next.js app router folder. I added a new page under apps/web/src/app/ventas/desarrollos/[id]/obra/page.tsx:

`diff
// apps/web/src/app/ventas/desarrollos/[id]/obra/page.tsx

"use client";
import { getApiBase } from "../../../../../lib/apiBase";
import { useEffect, useState } from "react";
import { useParams } from "next/navigation";
import { AuthGuard } from "../auth.guard"; +
export default function ObraPage

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-08-09

#playadev #buildinpublic

DEV Community: Roberto Luna

Automating Multi‑Channel Content Publishing: Adding Structured Bluesky Metadata to the Content‑Automation Repo

Automating Multi‑Channel Content Publishing: Adding Structured Bluesky Metadata to the Content‑Automation Repo

The Problem

What I Tried First

The Implementation

1. Define a Stable Schema

2. Update the Publishing Script

3. Adjust the CI Diff Generation

4. Commit Diff Summary

5. Validation Tests

Key Takeaway

What's Next

vibecoding #buildinpublic #nodejs #json #automation #devops #javascript

Migrating Console Logging to Structured Observability & Adding Theme Support in CrmShellCondos (v2.0.0)

Migrating Console Logging to Structured Observability & Adding Theme Support in CrmShellCondos (v2.0.0)

The Problem

What I Tried First

1️⃣ Direct Replacement in Each File

2️⃣ Adding a Wrapper Around console

The Implementation

1️⃣ Centralizing the Observability Helpers

2️⃣ Updating All 14 Files

apps/api/src/brokers/broker-portal.controller.ts

apps/api/src/ventas/pipeline-automation.service.ts

3️⃣ Fast‑Follow Theme Import in CrmShellCondos

4️⃣ Version Bump & Documentation

Key Takeaway

What's Next

Automating Multi‑Platform Publishing: Adding Bluesky Support to the Content‑Automation Repo

Automating Multi‑Platform Publishing: Adding Bluesky Support to the Content‑Automation Repo

The Problem

What I Tried First

The Implementation

1. Define a Bluesky payload schema

2. Extend the metadata schema

3. Wire the new payload into the CI script

4. Add changelog and markdown stubs

Integrating a Groq‑Powered WhatsApp AI Advisor into a NestJS API (pilot)

Integrating a Groq‑Powered WhatsApp AI Advisor into a NestJS API (pilot)

The Problem

What I Tried First

The Implementation

1. Environment schema update (apps/api/src/common/env.ts)

2. DB migration (apps/api/src/db/db.ts)

3. Groq helper extension (apps/api/src/shared/groq.helper.ts)

4. New WhatsApp AI controller (apps/api/src/whatsapp-ai/whatsapp-ai.controller.ts)

5. New WhatsApp AI service (apps/api/src/whatsapp-ai/whatsapp-ai.service.ts)

Automating Multi‑Platform Publishing: Fixing the Metadata‑Driven Build Pipeline

Automating Multi‑Platform Publishing: Fixing the Metadata‑Driven Build Pipeline

The Problem

What I Tried First

The Implementation

1. Add the missing front‑matter

2. Sync the Bluesky payload files

3. Update the automation script to validate metadata

4. Adjust the Docker entrypoint

5. Run the pipeline

Key Takeaway

What's Next

vibecoding #buildinpublic #javascript #nodejs #json #automation #docker

Debugging a Stale‑Cache Button in a Full‑Stack React App – Full Chronology & Fix

Debugging a Stale‑Cache Button in a Full‑Stack React App – Full Chronology & Fix

The Problem

What I Tried First

The Implementation

1. Document the Chronology

2. Expose the Cache Key in Code

3. Nginx Cache Invalidation Rule

4. UI Update – Hover SVG Fix

5. Production Build Verification

Key Takeaway

Adding Multilingual Bluesky URI Tracking to the Content‑Automation Metadata Schema

Adding Multilingual Bluesky URI Tracking to the Content‑Automation Metadata Schema

The Problem

What I Tried First

The Implementation

Diff – Adding language keys

Updating the post‑creation template

Adjusting the publishing script

2️⃣ Adding a Wrapper Around `console`

`apps/api/src/brokers/broker-portal.controller.ts`

`apps/api/src/ventas/pipeline-automation.service.ts`

3️⃣ Fast‑Follow Theme Import in `CrmShellCondos`

1. Environment schema update (`apps/api/src/common/env.ts`)

2. DB migration (`apps/api/src/db/db.ts`)

3. Groq helper extension (`apps/api/src/shared/groq.helper.ts`)

4. New WhatsApp AI controller (`apps/api/src/whatsapp-ai/whatsapp-ai.controller.ts`)

5. New WhatsApp AI service (`apps/api/src/whatsapp-ai/whatsapp-ai.service.ts`)

1. Stop caching `sw.js` in `next.config.mjs`

2. Clean up the service‑worker script (`public/sw.js`)

3. Fix the broken `/complexes` endpoint in seven pages

Bluesky Adapter (`adapters/blueskyAdapter.ts`)

Dev.to Adapter (`adapters/devtoAdapter.ts`)

2. NestJS controller – `ConstructionController`

Adding a “Control de Obra” Module to Ventas   Desarrollos (NestJS + Next.js)

Adding a “Control de Obra” Module to Ventas → Desarrollos (NestJS + Next.js)

1. Register the new controller in `AppModule`

2. New `ConstructionController`