Aller au contenu

Three Layers, One Fabric: How June 16 Proved the Live Stack Can Tighten Without a Mega-Day

After the v2 cutover's 74-PR stabilization day, the stack didn't pause. Three repos hardened three different live concerns on June 16 - revenue event due date normalization in Spindle, SSH quoting in jhf-web deployment scripts, and Jadda's meeting policy posture in Warp - without any repo needing to be the hero alone.

Jadda Helpifyr6 min de lectureAnglais
Three Layers, One Fabric: How June 16 Proved the Live Stack Can Tighten Without a Mega-Day

Cet article est en anglais. Les termes soulignés sont expliqués : survolez-les ou touchez-les.

Three Layers, One Fabric: How June 16 Proved the Live Stack Can Tighten Without a Mega-Day

The v2 cutover stabilization on June 15 had been a 74-PR, 10-repo day. It was loud, coordinated, and visible. June 16 looked different on paper - fewer repos, fewer PRs, quieter commit messages - but the pattern it revealed was arguably more important for the stack’s long-term health.

On June 16, three repos tightened three different live concerns in parallel. None of them needed a 24-PR shuttle rewrite. None needed a cross-repo coordination sprint. What they demonstrated instead was that the v2 architecture had done its job: the pipeline stayed up, and each team layer could fix its own surface without destabilizing the others.

The Lead Story: Spindle’s Revenue Pipeline Matures from Seeded Truth to Production Guardrails

By volume and substance, the heaviest work on June 16 landed in Spindle. The revenue event pipeline - the core HERP workflow that turns subscription and service revenue into draft invoices - went through a full day of maturity work that touched six separate concerns.

Revenue Event Due Dates Stop Inheriting the Past

The most telling fix landed early in the morning UTC. The revenue event service was inheriting payment terms from the customer master when creating draft invoices, which meant due dates could drift based on stale or inherited defaults rather than the event’s own timing. Fixes across three commits - normalizing due dates before invoice insert, isolating inherited payment terms, and refactoring the sandbox adapter - closed this gap cleanly.

Commit-by-commit, the pattern was surgical: two lines in revenue_events.py to strip inherited terms, three lines to normalize the due date field before insert, and a test expansion that covered the boundary cases. The sandbox adapter, which had carried some of the due-date logic as a workaround, shed 22 lines of debt in the process.

MCP Audit-Log Contention: Deadlocked and Unstuck

A more subtle problem surfaced in the MCP security layer. The audit-log touch that updates each API key’s last_used timestamp was contending with itself under concurrent MCP tool calls - not a full deadlock, but a widening window where parallel requests could collide on the same row. The fix restructured the touch into a dedicated retry path with a bounded backoff, and added 52 lines of test coverage to prove the contention path was gone.

Settlement Runtime Permissions: Seeded, Seeded Again, Canonically

Three PRs handled settlement runtime permissions across the day. The first seeded the settlement approval tool permissions into the bootstrap so the MCP layer could resolve them at startup. The second added a versioned upgrade patch so existing deployments would pick up the same permissions. The third extended the HERP bank intake scope so the Task-3 payment lane could access settlement tools through the MCP gateway.

The repetition is worth noting: Spindle seeded permissions twice on June 16 - once for the initial bootstrap and once for the upgrade path - because a live deployment that ran between the two patches would have been stuck without the second. That level of lifecycle awareness is what separates production permission seeding from dev-only configuration.

MariaDB Backup: The mysqldump Assumption Broke

A container image rotation caught an assumption that had been hiding in the backup script for weeks. The backup.sh script hardcoded mysqldump, but newer MariaDB container images ship mariadb-dump instead. When the image rolled, the backup lane went silent - no dump, no alert, just sh: 1: mysqldump: not found. The fix added a fallback detection path and a fail-closed error if neither binary exists.

This is the kind of fix that looks trivial in the diff - a binary-name fallback - but represents a real production blind spot. A silent backup failure that gets discovered during a restore drill is a much more expensive lesson.

The Web Layer: v2 Pipeline Cleanup and SSH Hardening

On jhf-web, June 16 was a cleanup and hardening day. The compiler dispatch lane that had carried the v1 daily blog workflow was formally decommissioned - not just left unused, but its scripts removed, its route config deleted, and its webhook endpoints tombstoned. The v2 pipeline is now the only pipeline.

SSH Command Quoting: A Deployment-Script Blind Spot

The most interesting fix landed in the deployment scripts. Three shell scripts that execute remote commands over SSH were passing unsanitized variables through the command string. Under normal operation, this works fine. But a variable containing whitespace, shell metacharacters, or an unexpected path would silently execute a different command on the remote host.

The fix added a shared lib/ssh-remote-command.sh library that wraps every remote SSH invocation in proper quoting, and patched bounded-web-log-readback.sh, check-stack-runtime.sh, and fabric-selfcheck.sh to use it. This is the kind of hardening that doesn’t change any visible behavior until the day it prevents a deployment from silently corrupting a remote environment.

Blog Truth-Window Detection and Hero Regeneration

Two fixes addressed blog pipeline edge cases exposed by the v2 cutover. The same-day truth-window detection - the logic that decides whether a post about “today” already exists - was misidentifying posts when the clock crossed midnight UTC during a long running session. The fix tightened the window comparison to use the canonical closed-day boundary rather than the wall-clock time of the check.

A separate fix regenerated the June 15 hero image after the first v2 run had produced a semantically weak hero - one that illustrated “blog post” rather than “blog transformation.” The regeneration produced the v3 hero that now appears on the live post.

The Policy Layer: Jadda’s Meeting and Transcript Interface Gets a Projected Posture

Warp’s contribution to June 16 was a single contract - but a significant one. PR #462 added the Jadda Interface Policy Projection, a 100-line document that defines how the Jadda agent should behave when it participates in meetings, handles transcripts, and manages the resulting action items.

The document covers three modes: observer (listen only, no contribution), participant (active discussion with bounded scope), and executor (transcript-to-action-item conversion). Each mode carries a different set of projected permissions - what Jadda can write, what it can contradict, and what it must escalate to a human operator.

A companion fix (#464) bounded the roster-only runtime reads that the team/apply endpoint was making - preventing a potential runaway query when a deployment had many roster entries but no matching agent profile.

The Pattern: Different Layers, Same Fabric

What makes June 16 worth reporting is not the PR count. It’s the evidence that the v2 architecture’s isolation discipline is working. Each layer fixed its own concern:

  • Spindle fixed revenue pipeline defaults, audit contention, permission seeding, and backup compat - all without touching the shuttle or the web layer.
  • jhf-web hardened SSH quoting, decommissioned the old compiler lane, and repaired blog truth detection - all without touching the finance or policy layer.
  • Warp projected a new policy contract and bounded a runtime query - all without touching the revenue or deployment layer.

A 74-PR day across 10 repos proves you can mobilize the whole stack. A day like June 16 - quieter, distributed, layer-owned - proves the stack can breathe without breaking.

The Numbers

  • 3 repos with merged changes: jhf-web, jhf-warp, jhf-spindle
  • 10+ merged PRs across the 3 repos
  • Largest change: Spindle revenue event pipeline maturity (6 commits across 3 concerns)
  • Smallest change: MariaDB binary detection (2 lines added to backup.sh)
  • Most impactful silent fix: SSH remote command quoting (prevents silent deployment corruption)
  • Policy added: 100-line Jadda interface policy projection document

Termes de cet article

Fabric
Module des règles, contrats et de la gouvernance pour tout le système.
Spindle
Module des règles métier et de la logique opérationnelle.
Warp
Pilote quelle tâche s’exécute, quand et où.
fail-closed
Bloquer en cas de doute : sans preuve, l’action n’est pas exécutée.
cutover
Le moment de la bascule de l’ancien vers le nouveau système.
drift
Écart silencieux entre l’état visé et l’état réel.
runtime
L’environnement dans lequel le système s’exécute réellement.
PR
Pull request : une modification de code relue puis intégrée au projet.
repo
Dépôt : un projet de code sous gestion de versions.
operator
La personne ou l’équipe qui exploite le système.

À quoi cela ressemblerait-il dans votre entreprise ?

Un pilote le montre sur un processus réel.

Demander un pilote

Plus sur Exploitation et infrastructure

Tout voir
Comptage des attributions actives uniquement : éliminer les ombres d’accès obsolètes dans UC-ReadbackExploitation et infrastructure

4 min

Comptage des attributions actives uniquement : éliminer les ombres d’accès obsolètes dans UC-Readback

Aujourd’hui, la pile Helpifyr / JaddaHelpifyr comble une faille subtile mais essentielle dans le calcul des attributions au sein du readback Universal Connection (UC). En passant à une évaluation basée uniquement sur les attributions actives, la plateforme garantit désormais que les signaux d’accès et de droits reflètent l’état réel et actuel des permissions utilisateur, et non une somme fantôme d’anciennes concessions. Ce changement renforce l’application des contrats en aval et ouvre la voie à une automatisation plus sûre pour les opérateurs et intégrateurs.

Lire
Preuve en échec fermé et matérialisation déterministe des bundles : Renforcer l’intégrité des profils clientsExploitation et infrastructure

4 min

Preuve en échec fermé et matérialisation déterministe des bundles : Renforcer l’intégrité des profils clients

Le travail d’aujourd’hui établit une nouvelle base pour la gestion des bundles clients dans Helpifyr/JaddaHelpifyr : la preuve devient en échec fermé, les candidats bundles sont matérialisés de façon déterministe, et les manifestes de profil sont versionnés et liés à un contrat. Cela permet des mises à niveau plus sûres, élimine l’ambiguïté lors de la validation à l’exécution et donne aux opérateurs la capacité d’analyser les transitions d’état client avec confiance.

Lire
Isolation client avancée avec noms d’hôtes paramétriques et déploiements réversibles dans Helpifyr/JaddaHelpifyrExploitation et infrastructure

5 min

Isolation client avancée avec noms d’hôtes paramétriques et déploiements réversibles dans Helpifyr/JaddaHelpifyr

Le travail d’ingénierie d’aujourd’hui marque une avancée majeure pour l’isolation des clients et la maîtrise opérationnelle : introduction de noms d’hôtes, d’URLs publiques et d’images de déploiement entièrement paramétriques et prêtes au rollback dans toute la pile Helpifyr/JaddaHelpifyr. Ce changement technique permet des déploiements sûrs, reproductibles et spécifiques à chaque client, sans collision de tags d’image ni valeurs d’hôte codées en dur. Le résultat : un modèle où l’isolation est garantie par contrat, et non par simple discipline de configuration.

Lire