validate-site.mjs
When to use: before tagging a release or merging routing/layout changes.
Download: /downloads/validate-site.mjs
The JTL Automation API Model
The Automation Toolkit is intentionally designed as an internal engineering API for the JustineLonglaT-Lane ecosystem — a stable interface that standardizes how work is requested, validated, executed, and released across repositories, sites, and environments. The diagram below models the Toolkit as a single orchestrator that coordinates eight complementary layers of automation:
- API Intent — clarifies why automation exists and the outcomes it must deliver (reliability, repeatability, and safe releases).
- API Surface — makes capabilities discoverable through well-structured, reusable assets (scripts, templates, and CI building blocks).
- API Pipeline — orchestrates predictable, repeatable workflows from validation to deployment.
- API Safety — enforces guardrails such as pre-checks, linting, and validation before changes ship.
- API Assets — provides reusable automation primitives that teams can compose instead of reinvent.
- API Catalog — acts as a searchable index of tools, patterns, and recommended practices.
- API Error Handling — ensures graceful recovery through rollback, logging, and remediation paths.
- API Contract — formalizes expectations via release checklists, quality gates, and repeatable standards.
Thinking in terms of an Automation API allows the Toolkit to scale, remain consistent, and integrate naturally with CI/CD, cloud infrastructure, and platform engineering practices across the JustineLonglaT-Lane ecosystem.
API Diagram
Why this Automation Toolkit API exists
The Automation Toolkit API Model defines a shared interface for how engineers interact with automation. Instead of ad-hoc scripts and manual steps, every action becomes a well-defined “API call” with clear intent, inputs, and outcomes.
The Automation Toolkit is designed as a single, repeatable Automation API for shipping safely. Instead of scattered scripts, everything flows through one mental model: This section describes the API surface of the Automation Toolkit — the standardized tools, templates, and primitives you can call from any repository.
- Inputs → Operations → Outputs
- Inputs: pages, posts, metadata, links, templates
- Operations: validate, preview, tag/release, deploy, recover
- Outputs: clean builds, stable URLs, reproducible releases
Think of this page as both documentation and a control plane for the Automation Toolkit API.
- Fast: lightweight commands you can run daily.
- Safe: guardrails around risky operations.
- Reproducible: the same workflow across projects.
- Explainable: every tool has a clear role in the pipeline.
Mental model: Create → Validate → Preview → Release → Deploy → Recover.
What the Toolkit API provides
- Local clients (PowerShell helpers): tools that act like “SDKs” for working with your repo.
- Server-side checks (CI/CD): automated validation in GitHub Actions and Vercel.
- Shared contracts (templates): predictable YAML, routing, and layout patterns.
- Runbooks: documented procedures for calm releases and recovery.
The Toolkit API workflow
- Input (Create): add pages, posts, or scripts in predictable paths.
- Validate: run checks for links, anchors, routes, and collisions.
- Preview: verify locally before opening a PR.
- Release: batch changes cleanly and tag a freeze point.
- Deploy: ship from a known-good baseline (consistent output).
- Observe: confirm production behavior matches local intent.
In the Toolkit API Model, every change flows through a predictable request pipeline — from local development to CI validation, to guarded release.
Guardrails act as the policy layer of the Toolkit API, ensuring consistency, security, and reliability before anything reaches production.
- Pre-ship validation: catch broken links, bad routes, and missing metadata.
- Freeze points: keep stable reference tags you can always roll back to.
- Safe history operations: avoid destructive rewrites of main.
- Clean releases: ship small, explainable batches with predictable diffs.
Downloads represent the official artifacts produced by the Toolkit API — reusable, versioned outputs you can adopt across projects.
- Toolkit API Overview (PDF)
- PowerShell SDK (Starter Pack)
- validate-site.mjs (API validator)
- Tag-Release.ps1 (release controller)
- bust-styles.ps1 (style normalizer)
Future improvement: publish SHA256 checksums for artifact integrity.
Toolkit API components
Each tool below represents a function in your Toolkit API — you call it at a specific moment in the lifecycle.
bust-styles.ps1
When to use: after refactors when CSS/formatting gets noisy.
Download: /downloads/bust-styles.ps1
Tag-Release.ps1
When to use: when you want a clean freeze point / release tag.
Download: /downloads/Tag-Release.ps1
Templates
When to use: restore known-good layout blocks (hero/header/index variations).
Path: /templates/
Tip: publish new helpers under /public/downloads, then add them here so links stay stable.
The Tool Index is your endpoint catalog — a curated list of automation capabilities exposed by the Toolkit API./h2>
Quick reference to every toolkit tool — what it does, when to use it, and how to run it.
Source-of-truth lives in the repo; downloads are stable copies in /public/downloads.
| Tool | Purpose | When to use | Command |
|---|---|---|---|
| inject-partials.mjs | Rebuilds header/footer across all pages. | After editing partials or page layout. | node ./scripts/inject-partials.mjs |
| check-partials.mjs | Validates partial markers exist and match. | Before merge or release tag. | node ./scripts/check-partials.mjs |
| check-heroes.mjs | Ensures hero blocks are consistent. | When editing home/landing layouts. | node ./scripts/check-heroes.mjs |
| partials-guardrails.yml | CI guardrails for partial safety. | Used in GitHub Actions. | runs automatically in CI |
| hero-guardrails.yml | CI guardrails for hero consistency. | Used in GitHub Actions. | runs automatically in CI |
| validate-site.mjs | Checks internal links and anchor drift. | Before tagging a release. | node ./downloads/validate-site.mjs |
| Tag-Release.ps1 | Canonical release tagging helper. | When freezing a milestone. | ./downloads/Tag-Release.ps1 |
| bust-styles.ps1 | Cleans noisy CSS diffs. | After big refactors. | ./downloads/bust-styles.ps1 |
Tip: when you add a new tool, add it to /public/downloads, then register it here so links stay stable.
Rollback defines the Toolkit’s error-handling behavior — how the system recovers safely when a deployment fails.
- Prefer revert over rewrite: keep history clean.
- Use freeze tags: restore from known-good states.
- Recover method: checkout tag → validate → fix → redeploy.
- No panic edits: resolve issues through Git, not quick hacks.
Toolkit endpoints (tool catalog)
Think of the Automation Toolkit as a lightweight “API” for your repository: predictable inputs, safe operations, and reliable outputs.
- Inputs: pages, posts, links, metadata, and templates.
- Operations: validate, preview, tag, deploy, recover.
- Outputs: clean builds, stable URLs, and reproducible releases.
Each tool below behaves like a small, focused endpoint in your Toolkit API.
The Release Checklist serves as the API contract — a formal definition of what a “valid release” must satisfy.
- Local sanity: home, README, and toolkit layout are centered and consistent.
- Link validation: header/footer links return 200.
- Clean diff: separate refactors from content changes.
- Freeze point: tag a stable release with Tag-Release.ps1.
- Deploy: confirm Vercel builds the correct branch.
- Post-deploy verify: test in incognito; theme toggle + nav must work.