Adds a first-class TypeScript code generator to speckl-compile that emits:
- Const enum for workflow states (IssueWorkflowState)
- Strongly-typed class with guards, state transitions, decision log
- Proper this. prefixing (state vars only, not local params)
- Enum references instead of string literals for state comparisons
- Clean tsc --noEmit compilation
Also includes:
- specs/forgejo-issue-workflow.speckdl — full workflow with 9 actions,
8 constraints, 5 temporal verifications
- Generator deduplication of duplicate AST nodes
- Support for init block initialization of state variables
The generator was validated against the Forgejo issue workflow spec,
producing IssueWorkflow.ts that compiles with zero errors.
Refs: heartbeat conversation re: speckl-compile extensibility
- Fixed speck name regex to allow hyphens (\w → [\w-])
- Added provenance { } block handling in parseMember()
- Updated hyphenated name test from 'My' to 'My-Service-Handler'
- All 48 tests passing (27 parser + 21 validator)
- Connected PROV-O, CycloneDX, and SPDX generators to CLI entry point
- Fixed parseAuthor regex to handle angle-bracket email format
- Fixed parseDerives to handle hyphenated names and quoted rationale
- Fixed parseSatisfies to handle hyphenated requirement IDs
- Fixed parseSource to handle ref keyword with quoted value
- Added graceful fallbacks (warn instead of throw) for parse errors
- All 5 example .speck files compile and validate successfully
- Switched from grid auto-fit to flexbox with justify-content: center
- Cards: flex-basis 30%, min 260px, max 360px
- Bottom row of 2 cards now centered under 1-2 and 2-3 positions
- Replace 'AI-generated, human-owned' with 'Two-Species Collaboration'
- Add 'Compiles to Wasm' as a distinct philosophy point
- README: new 'Chain of Custody for Intent' section
- Landing: updated hero tagline and philosophy cards
- SpeckDL compiles directly to Wasm through deterministic pipeline
Human intent is encoded in SpeckDL because it is judgeable by a person.
SpeckDL is useful for agentic work because it is easy for AI to write and reason about.
- Removed inaccurate multi-agent system description and architecture SVG
- Replaced with honest framing: Speckl is an open standard (methodology + language spec)
- Removed Discord CTA button per Scott's request
- Removed stale favicon.svg from landing dir
- General polish: hero layout, mobile breakpoints
- CLI entry point with yargs parsing for speckl-compile <file> --output-dir --bom-format
- TypeScript parser with AST types for all SpeckDL primitives
- Generator for PROV-O JSON-LD provenance graphs
- Generator for CycloneDX v1.6 BOMs
- Generator for SPDX 3.0.1 BOMs
- E2E test verifying RetryHandler.speck parsing and all output formats
All tests pass.
Old: D (Open Standard) → C (Consulting) → A (SaaS) → B (Compliance)
New: A (Open Standard) → B (Consulting) → C (SaaS) → D (Compliance)
Updated: README.md, strategy.md, plan-flow.svg, landing page
Static dark-mode site with hero, features, SpeckDL code example,
philosophy section, and roadmap. Deployed via NixOS module to
speckl.scoble.me with Cloudflare ACME DNS challenge.
SpeckBOM compilation manifest now supports two output formats:
- CycloneDX v1.6 JSON (OWASP/ECMA-424) — preferred for security tooling
- SPDX 3.0.1 JSON-LD (ISO 5962:2023) — preferred for regulated environments
Key changes:
- §4.5: Restructured as 'Compilation Manifest (SpeckBOM Output)' with dual format
support, comparison table (CycloneDX vs SPDX capabilities), both JSON examples,
and separate field mapping tables for each format
- Added compiler output section: --bom-format cdx|spdx|both (default: both)
- Appendix B restructured into 4 sections:
B.1 Provenance Graph (JSON-LD / PROV-O) — intent layer
B.2 SpeckBOM — CycloneDX v1.6 mapping table
B.3 SpeckBOM — SPDX 3.0.1 mapping table
B.4 Three-layer architecture: intent (PROV-O) + composition (CycloneDX or SPDX)
Rationale: Different regulators mandate different formats. DO-178C shops
need SPDX (ISO normative), security teams need CycloneDX (OWASP ecosystem).
Supporting both makes SpeckBOM universally adoptable.
Replace custom JSON-LD compilation manifest with valid CycloneDX v1.6
documents using bomType: specBOM and speckl: property namespace.
Key changes:
- §4.5: Compilation manifest now outputs CycloneDX v1.6 JSON
- Added 'Why CycloneDX' section comparing CycloneDX vs SPDX for this use case
- Full CycloneDX JSON example for DrugDosageCalculator
- Added CycloneDX field mapping table (SpeckDL primitive → CycloneDX location)
- Added path to standardization (community proposal → OWASP recognition)
- Appendix B restructured into three sections:
B.1 Provenance Graph (JSON-LD / PROV-O) — intent layer
B.2 SpeckBOM (CycloneDX v1.6) — composition layer
B.3 Two-Layer Architecture — how they complement each other
This extends an existing OWASP/ECMA-424 standard rather than defining
a bespoke format, ensuring compatibility with Dependency-Track and
the full CycloneDX tooling ecosystem.
New language features:
- bom {} block: declares toolchain dependencies (compiler, solver, runtime),
license, and content hash — the spec analog of an SBOM
- Import version pinning: hash and version on import statements for
reproducible builds and dependency integrity
- §3.6.6: SpeckBOM semantics — maps each bom clause to JSON-LD/SPDX
- §3.6.7: Import pinning semantics — hash verification at compile time
- §4.5: Compilation manifest — auto-generated audit-ready JSON-LD output
with spec hash, dependency integrity, toolchain versions, artifact hashes,
verification results, and reproducibility flag
- Updated EBNF grammar for bom_def and import hash/version
- Updated examples (InfusionPumpController shows bom block, PaymentService
shows import pinning)
- Updated Appendix B with SpeckBOM JSON-LD mappings
Together with existing DP primitives (provenance, review, derives, satisfies,
author, source), SpeckBOM provides the full picture: intent provenance +
composition manifest + verification evidence = audit-ready specification.
New language members: provenance, review, derives, satisfies, author, source
- provenance block: declare intent sources (regulation, design_decision, parent_spec, external_doc)
- review directive: mark verification boundaries (manual, auto, hybrid)
- derives/satisfies: spec-to-spec and spec-to-requirement edges
- author/source: who wrote it and what drove it
- Provenance-aware event semantics: runtime events trace back to intent
- Updated EBNF grammar, semantics, examples, and JSON-LD mapping
- Three new examples: regulated medical device, auto-verified service, compliance audit trail
- All primitives optional — Specks without provenance still compile fine
- docs/blog/2026-04-28-why-dark-provenance.md: First blog post explaining the vision
- docs/content-calendar.md: 2-week content plan with themes and targets
- docs/warp-monitoring.md: Process for monitoring Warp and engaging thoughtfully
Part of the build-in-public campaign for Speckl (Dark Provenance for AI agents).
- Dark Provenance whitepaper: complete sections 2-6 (What Is Dark Provenance,
The Speckl Approach, Semantic Preservation & SA-11, Implications, Call to Action)
- README: public launch-ready with architecture, roadmap, getting started
- SpeckDL SPEC.md: v0.1 language specification with EBNF grammar,
type system, compilation pipeline, 5 example Specks
- Reference agent: TypeScript scaffold with Orchestrator, TeamLead, SMEs
(VerificationSME, CodegenSME), TillDone condition tracking,
ProvenanceGraph, and CLI with example Specks
- MIT license
- README with project overview, Dark Provenance intro, and structure
- Empty directories: speckdl/, reference-agent/, examples/
- Placeholder whitepaper with Dark Provenance outline
Parent: Greybeard Holdings, LLC
Status: Early / Pre-Alpha
