HOWL // HOWLBOARD SYS_ID: HB-EVAL-05
[ VIEW ON GITHUB ]
EVALUATION_CONSOLE // FULL-STACK REFERENCE APPLICATION: HOWLFRAME DOGFOODING & STATE INVARIANTS

// observation / stress testing / evaluation surface

HowlBoard

HowlBoard is the flagship external consumer and reference application for HowlFrame, engineered by William Elias. It is a full-stack mission-control interface for governed autonomous engineering work, built strictly with HowlFrame for both the browser client (web_app) and the backend (http_server compiled to standalone bytecode).

AXIOM // APPLICATION FEEDBACK DRIVES PLATFORM MATURITY. The goal is not another task board. The true goal is to prove how much of a legitimate full-stack system can be expressed through HowlFrame, discover compiler bugs, and harden the language under real application stress.
[ CLONE REPOSITORY ] [ INTERACTIVE DEMO ] [ DOGFOOD EVIDENCE ]
STACK_FLOW // FRONTEND COMPILATION ↔ REST API ↔ BYTECODE VM PERSISTENCE: DUAL FILE STORES
01 // FRONTEND
frontend/*.howl
Compiles via HowlFrame JS backend into app.js making native browser DOM mutations.
[TARGET: JAVASCRIPT]
02 // PROTOCOL
HTTP / REST API
Async JSON payloads for task updates, status moves, and activity feed telemetry.
[PORT: 8080]
03 // BACKEND
backend/*.howl
Compiles to server.hfbc bytecode running inside the HowlFrame VM under finite budget.
[RUNTIME: BYTECODE VM]
04 // PERSISTENCE
Native Record Store
Persisted to howlboard.json & howlboard_activity.json across restarts.
[STORAGE: DURABLE]

SECTION // 01 Purpose & Feedback Loop

HB-MOD-PURPOSE

HowlBoard acts as the primary evaluation surface for HowlFrame. By strictly using HowlFrame for both the frontend JavaScript generation and the bytecode backend, it continuously exercises the platform's ability to handle CRUD, state mutations, deterministic transition rules, and browser interaction.

The feedback loop is direct: Application requirement → HowlFrame implementation → Compiler/runtime friction → Language/runtime improvement → Application continues.

SECTION // 02 Full-Stack Architecture

HB-MOD-ARCH
[SCHEMATIC // FULLSTACK_PIPELINE] FLOW_GRAPH 
frontend/app.howl
      │
      ▼
HowlFrame JS Backend (Emitter)
      │
      ▼
Browser DOM & Vanilla JavaScript (app.js)
      │
      │  HTTP REST / JSON Requests
      ▼
backend/server.howl
      │
      ▼
HowlFrame Bytecode Compiler (-compile-bc)
      │
      ▼
HowlFrame Bytecode VM (server.hfbc)
      │
      ▼
File-Backed Native Record Stores (howlboard.json & howlboard_activity.json)

SECTION // 03 Mission Control Showcase

HB-MOD-DEMO

A read-only view of the same five demo missions the running application loads. This page is static: there is no server behind it, so approvals, state transitions and rejections are not available here. Select a mission to trace it from evidence through to outcome.

These missions describe plausible Howl ecosystem work and are marked DEMO. They are not records of real executions. The application can additionally ingest real HowlPlane control-plane ledger entries, which carry LEDGER provenance instead.

MISSION CONTROL // READ-ONLY SHOWCASE AUTHORITY DERIVED AT RENDER TIME

SECTION // 04 Dogfooding Evidence & Discovered Fixes

HB-MOD-EVIDENCE

Building HowlBoard directly surfaced missing primitives and bugs in HowlFrame, which were fixed upstream:

Discovered Friction / Bug Subsystem Affected Resolution in HowlFrame Status
HTML DOM Mutability JS Backend & IR Added set_html and toggle_class to HowlFrame's IR and JS emitter RESOLVED
Network & CORS Headers HTTP Server Runtime Added req_method and res_header capability opcodes to VM RESOLVED
Type Checker AST Panics Frontend Checker Registered try_let and parse_json in JS backend checker walker RESOLVED
Browser Input Value Reads JS Backend Added dom_value primitive to read text inputs without raw JS hacks RESOLVED

SECTION // 05 Capability & State Policy Model

HB-MOD-POLICY

HowlBoard enforces a deterministic mission state machine. A mission cannot skip a lifecycle stage, and separately, it cannot enter EXECUTING at all without live delegated authority — the state machine and the authority envelope are two independent gates:

[HOWL // POLICY_INVARIANT] TRANSITION_GATE 
(defun can_transition (from to)
  (type_hint return "bool")
  (let (ok false)
    (do
      (if (and (= from "CREATED") (= to "ROUTED")) (set ok true) (do))
      (if (and (= from "ROUTED") (= to "EXECUTING")) (set ok true) (do))
      (if (and (= from "ROUTED") (= to "AWAITING_APPROVAL")) (set ok true) (do))
      (if (and (= from "AWAITING_APPROVAL") (= to "EXECUTING")) (set ok true) (do))
      (if (and (= from "EXECUTING") (= to "VERIFYING")) (set ok true) (do))
      (if (and (= from "VERIFYING") (= to "COMPLETED")) (set ok true) (do))
      (if (and (= from "VERIFYING") (= to "REMEDIATING")) (set ok true) (do))
      ;; ... full table in backend/server.howl
      (return ok))))

SECTION // 06 Build & Run Instructions

HB-MOD-BUILD
[BASH // BUILD_AND_RUN] 
# 1. Clone repositories side-by-side
git clone https://github.com/howlcipher/howlframe.git
git clone https://github.com/howlcipher/howlboard.git

# 2. Build HowlFrame compiler binary
cd howlframe
go build -o ../howlboard/howlframe_bin howlframe.go

# 3. Build HowlBoard (compiles frontend JS and backend HFBC)
cd ../howlboard
make build

# 4. Run the backend VM server
make run

# 5. In a separate terminal, serve the frontend assets
make run-frontend

SECTION // 07 Implementation Status & Roadmap

HB-MOD-STATUS

Completed Features

  • Full frontend and backend compilation via HowlFrame
  • Deterministic mission state transitions
  • Native disk store persistence (survives restart)
  • Real-time telemetry event logging

Active Exploration

  • String interpolation ergonomics in Howl AST
  • Complex array loops in REST JSON decoding
  • Live HowlPlane control-plane ledger streaming

SECTION // 08 Technical Q&A: Deterministic State Machines & Language Dogfooding

HB-MOD-QA

How does HowlBoard dogfood the HowlFrame language compiler and runtime?

HowlBoard serves as the primary evaluation surface for the HowlFrame toolchain. By expressing both client-side DOM interactions (compiled to JavaScript) and backend server logic (compiled to sandboxed bytecode .hfbc) exclusively in .howl source files, HowlBoard exercises compiler optimizations, type safety boundaries, and disk persistence under real application workflows.

Why is deterministic state transition enforcement critical for autonomous work?

In safe autonomous systems engineered by William Elias, state cannot mutate arbitrarily. The can_transition policy function strictly restricts state progression, and authority is derived on every read rather than replayed from storage, so an approval that has lapsed presents as ENVELOPE_EXPIRED and execution is refused. Together these eliminate invalid states and unauthorized mutations across multi-agent workflows.

How does HowlBoard integrate with the wider Howl ecosystem?

As part of the Howl ecosystem, HowlBoard works alongside HowlPlane for control orchestration, HowlChangeOps for release authority gating, and HowlRelay for immutable audit logging.