Platform Help

Kurocado Studio Platform

Introduction

This site documents the Kurocado Platform — a shared engineering foundation designed to support multiple products, teams, and applications without duplicating infrastructure or re-solving the same problems.

The Platform centralizes architecture, workflows, tooling, and standards that would otherwise be rebuilt independently across projects. It is intentionally modular, composable, and framework-aware.

This documentation focuses on how the platform works, why certain decisions were made, and how its pieces fit together.

Getting Started

Use this order. If you skip it, you get inconsistent linting, CI drift, and unstable releases.

1. Install the Engineering Styleguide

Start by adopting the shared styleguide package so your repository uses the same TypeScript, ESLint, Prettier, commitlint, and release conventions as the Platform.

  1. Add @kurocado-studio/styleguide to your project.

  2. Wire the exported configs into your local tooling.

  3. Run lint/typecheck/format to verify the integration.

For implementation details, follow Engineering Styleguide.

2. Choose Reusable Workflows

After the styleguide is in place, opt into the reusable CI/CD workflows you need.

Typical order:

  1. workflow.lint.yml

  2. workflow.test.yml

  3. workflow.document.yml (if you publish docs)

  4. workflow.release.yml

Pick only what your product needs. Do not enable release or deploy workflows before lint and test are stable.

3. Validate End-to-End

Run the full pipeline once in a branch:

  1. Install dependencies.

  2. Run lint, typecheck, and tests locally.

  3. Push and verify the selected GitHub workflows complete successfully.

If any step fails, fix the contract mismatch before adding more workflows.

Vision

The vision of the Platform is to treat engineering infrastructure as a reusable system rather than project-specific configuration.

Modern products often rebuild the same tooling repeatedly: CI pipelines, package structures, lint rules, testing patterns, and release workflows. Over time this duplication slows teams down and makes it difficult to maintain consistency across projects.

Platform provides a shared foundation where these concerns are solved once and reused across products. Applications can focus on product logic while the platform provides predictable tooling, automation, and conventions.

The long-term goal is an ecosystem where new products can be created quickly while still inheriting the same engineering standards, workflows, and infrastructure.

Mission

The mission of the Platform is to provide a stable engineering foundation for building and operating multiple products.

Design Principles

The Platform is guided by a small set of principles that recur throughout the documentation:

  • Leverage over duplication Shared solutions should reduce total system cost, not add abstraction for its own sake.

  • Explicit boundaries Packages, domains, and responsibilities are defined intentionally to avoid hidden coupling.

  • Incremental adoption Teams should be able to adopt platform components without full buy-in or rewrites.

  • Transparency Architecture, workflows, and tradeoffs are documented openly to enable trust and scrutiny.

Platform Scope

The Platform provides shared foundations across several dimensions:

  • Architecture System boundaries, domain modeling, package topology, and runtime concerns.

  • CI/CD Automated workflows for testing, versioning, previews, and releases.

  • Developer Experience Shared tooling and packages that standardize how applications interact with APIs, configuration, and infrastructure.

  • Quality & Testing Testing strategy, QA tooling, and shared utilities designed to scale across applications.

Last modified: 05 March 2026
Engineering Styleguide