Skip to content

Repository files navigation

Plattar Platform

Plattar Stack 2.0 is an end-to-end SaaS platform for creating, configuring, and embedding 3D product scenes and AR experiences in the browser. This umbrella repo is the source of truth for the platform: it holds the central Spec Kit constitution, all cross-repo documentation, and the canonical cross-repo specs and contracts. The four product pillars live here as git submodules — clone once and you have the whole stack, while each pillar remains an independent repo with its own remote, CI, branches, and release cadence.

Repository layout

plattar-platform/                  # umbrella repo (this repo)
├── .specify/
│   └── memory/
│       └── constitution.md        # central Spec Kit constitution (governs all pillars)
├── shared-config.md               # shared tooling/config conventions referenced by every pillar
├── README.md                      # this file
├── docs/
│   ├── architecture.md            # cross-repo system architecture
│   ├── onboarding.md              # new-developer setup & first contribution
│   ├── feature-workflow.md        # cross-repo spec-driven feature flow
│   ├── glossary.md                # shared vocabulary (PEX, cm-scale, fixtures, …)
│   └── pillars/
│       ├── plattar-renderer-sdk.md
│       ├── plattar-components.md
│       ├── plattar-viewer.md
│       └── plattar-cms.md
├── specs/
│   ├── README.md                  # index of canonical cross-repo specs
│   └── contracts/
│       ├── renderer-api.md        # programmatic engine + <plattar-embed> contract
│       ├── design-tokens.md       # --theme-* / --font-* theming bridge contract
│       └── scene-schema.md        # canonical scene/product/variation data shape
│
├── plattar-renderer-sdk/          # submodule → github.com/Plattar/plattar-renderer-sdk
│                                  #   npm: @plattar/renderer (NEW, greenfield, Babylon.js)
├── plattar-components/            # submodule → github.com/Plattar/plattar-components
│                                  #   npm: @plattar/react-components (existing, React 19 + Vite)
├── plattar-viewer/                # submodule → github.com/Plattar/plattar-viewer
│                                  #   app: Next.js 16 static-export configurator SPA (existing)
└── plattar-cms/                   # submodule → github.com/Plattar/plattar-cms
                                   #   app: Next.js 16 authoring tool (NEW, greenfield)

Pillars

Pillar Repo Package / App Status Stack Consumes
plattar-renderer-sdk Plattar/plattar-renderer-sdk npm @plattar/renderer New (greenfield) Babylon.js, ESM + CJS + .d.ts
plattar-components Plattar/plattar-components npm @plattar/react-components Existing (healthy) React 19, Vite library build, Storybook
plattar-viewer Plattar/plattar-viewer App (customer-facing) Existing Next.js 16 + React 19, static export @plattar/renderer, @plattar/react-components
cms Plattar/plattar-cms App (admin / authoring) New (greenfield) Next.js 16 + React 19 @plattar/renderer, @plattar/react-components

The renderer replaces the legacy Three.js plattar-core renderer and the published <plattar-embed> embed shim, exposing both a typed programmatic engine API and a drop-in <plattar-embed>-style web component. The plattar-components library carries the CSS-variable design-token layer that is the live theming bridge for host apps and the CMS. See docs/pillars/ for per-pillar detail.

Dependency & release order

@plattar/renderer → @plattar/react-components → { plattar-viewer, cms }

The two npm packages (renderer, plattar-components) are published first; the two apps (plattar-viewer, cms) consume them. Merge cross-repo features in this dependency order. See docs/feature-workflow.md.

Clone

Get the whole stack — umbrella plus all four pillar submodules — in one command:

git clone --recurse-submodules git@github.com:Plattar/plattar-platform.git

Already cloned without submodules? Pull them down:

git submodule update --init --recursive

The umbrella pins each submodule at a specific commit SHA. Each submodule is a full, independent repo — cd into it to branch, build, and push against its own remote.

Spec-driven development

The platform uses GitHub Spec Kit (pinned to v0.11.5, Claude integration, PowerShell scripts) for spec-driven development. Spec Kit is per-repo and keys its state off the git branch name, so the model is:

  • Central constitution + canonical specs live here, in .specify/memory/constitution.md and specs/. This is the governing layer for every pillar.
  • Each pillar has its own Spec Kit setup plus a CLAUDE.md overlay that points back to this central constitution and to shared-config.md.

Spec Kit installs as Claude skills — invoke them from inside any repo:

/speckit-constitution · /speckit-specify · /speckit-clarify · /speckit-plan · /speckit-tasks · /speckit-analyze · /speckit-checklist · /speckit-implement · /speckit-converge

Cross-repo features get one feature ID assigned centrally (e.g. 042-some-feature), reused as the git branch feat/042-some-feature, the PR title, and issue labels in every affected submodule — one agent and one PR per repo, merged in dependency order. All generated spec artifacts (spec.md / plan.md / tasks.md) are committed, never gitignored. Full procedure in docs/feature-workflow.md.

Where to go next

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages