Loom73 Roadmap¶
The roadmap describes planned work. Current behavior belongs in the component documentation and completed release work belongs in the changelog.
Loom73 evaluates additions against three questions:
- Does the problem recur across real applications?
- Is the capability useful without imposing an application-specific workflow?
- Does it belong in the core, an optional integration, or documentation?
6.0 — Public Foundation¶
Status: complete
Loom73 6.0 establishes the first public foundation of the project.
Completed foundation¶
PHP 8.3 minimum baseline
public landing and architecture pages
component demonstrations
responsive and accessible frontend baseline
tooltip and responsive navigation
404 and 500 responses
deployment workflow
runtime health inspection
repository pre-publication review
complete and reorganize repository documentation
document every current backend component
document frontend utilities and Stitch
align README and documentation links
finalize repository metadata and license presentation
prepare the first public 6.0 release
Version 6.0 should not gain another large subsystem.
6.1 — Frontend Modernization¶
Status: complete
Modernize the frontend architecture and toolchain while preserving the framework-free browser runtime.
Build foundation¶
Status: complete
The Node.js build runner provides:
CSS import bundling and minification
automatic theme entry discovery and compilation
JavaScript module bundling and minification
package-version injection
SVG optimization
configurable WebP conversion
font and static-asset copying
aggregate build and optimization tasks
development watch mode
development-only source maps
shared browser targets for CSS and JavaScript
esbuild metadata used for build metrics
source-aware error reporting
colored success and failure output
per-task and aggregate timing
The legacy Grunt pipeline and its plugins were removed after validating:
npm clean installation
one-off frontend build
deployment build
development watch mode
new and modified asset handling
generated public asset paths
frontend behavior
Frontend source contract¶
Status: complete
The frontend now uses explicit source entry points:
CSS dependencies are expressed through imports rather than a source list owned by the build runner.
JavaScript modules import their source files directly and are bundled into a single browser entry point.
Production builds generate deployable assets without source maps. Development watch mode generates linked source maps for CSS and JavaScript.
Browser targets are configured once in frontend-src/build.mjs and passed to both Lightning CSS and esbuild.
Layout contract¶
Status: complete
The core layout layer provides reusable page sections, bounded content, breakout sections and adaptable grid patterns.
The contract favors a small set of configurable layout primitives over a large collection of fixed grid combinations. Application-specific spacing, borders and presentation remain outside the reusable layout layer.
Theme boundary¶
Status: complete
The frontend is divided into:
Loom73 core
reusable structure, behavior and functional UI contracts
themes
colors, typography and component presentation
application
domain-specific visual decisions
Loom73 ships with the Plain theme:
Theme entry files are discovered by convention and compiled to standalone public stylesheets. Invalid or unavailable theme identifiers fall back to Plain.
The theme contract deliberately excludes:
Optional bundle-size guardrails remain a possible later improvement and are not a 6.1 release requirement.
6.2 — Gauge¶
Gauge is a small, opt-in request profiler. The runtime and activation flow are implemented.
Initial measurements:
response time
current memory
peak memory
database query count
database query time
PHP version
HTTP status
HTTP method and request path
Gauge:
remains disabled by default
can be enabled in development or explicitly in production
requires an authorized user and browser opt-in
stores no measurements in the database
sends no remote telemetry
adds minimal overhead
renders a small developer-facing status bar
Beam records query count and timing when it executes statements. Gauge reads the aggregate values for the current request. After a POST redirect, it can show a one-time snapshot of the previous POST alongside the GET; the snapshot expires after 120 seconds.
Shuttle operations:
php shuttle gauge.info
php shuttle gauge.enable
php shuttle gauge.enable --production
php shuttle gauge.disable
Instance activation uses storage/.loom73-gauge-enabled. Production requires --production while SYSTEM_STATUS=production. An authenticated user with view_gauge must also opt in through the browser. See the Shuttle reference for the activation commands.
Gauge measures the current request. Logger records operational failures. Ledger records meaningful user actions.
6.3 — Release and Upgrade Path¶
Formalize:
Introduce a safe distinction between:
loom73.install
create a fresh runtime and schema
loom73.update
apply missing changes to an existing instance
The first update mechanism should remain small:
record installed schema or blueprint version
discover ordered update scripts
run missing updates sequentially
record successful completion
stop and report failures
A full migration framework is not required.
Keep the code update boundary explicit:
- Loom73 controllers and models live under
lib/and can receive upstream updates. - Core configuration lives under
config/modules/; application-specific overrides live underapplication/config/modules/. - Application controllers and models, and all views, remain under
application/. Release notes must identify changes to the view contract. - Plain should remain upgradeable by separating theme defaults from instance-specific styling.
Code updates still require a reviewed Git merge. loom73.update applies database scripts only.
6.4 — Automated Confidence¶
Add focused tests around stable contracts.
Priority areas:
autoloading
routing and error responses
Config
Connection and QueryResult
Model CRUD and identifier validation
authentication and guards
Yarn validation, replacement and delivery
Ledger recording and retention
API responses and method restrictions
Shuttle command resolution
Add an installation smoke test:
Frontend confidence¶
Add focused browser automation around the public frontend contracts:
Playwright functional smoke tests
responsive viewport checks
navigation and component interactions
selected visual regression snapshots
@axe-core/playwright accessibility scans
Accessibility scans should cover both the initial document and meaningful interactive states, including:
expanded responsive navigation
open dialogs
visible tooltips
form validation feedback
sorted and paginated tables
revealed InView content
The target CI matrix is:
with:
Composer validation
platform requirement checks
PHP lint
focused tests
npm clean install
frontend build
frontend functional smoke tests
automated accessibility checks
deployment validation
6.5 — Public Discovery¶
Make search-engine exposure an explicit choice of each installed instance.
Indexing control¶
Indexing is disabled by default through two complementary mechanisms:
The versioned.htaccess checks for this instance-owned marker:
Possible shuttle operations:
The commands should coordinate bothrobots.txt and the .loom73-indexing-enabled marker.
indexing.info
report the marker state
inspect the global robots policy
warn when the two mechanisms disagree
indexing.enable
configure robots.txt to allow crawling
create the indexing marker
indexing.disable
remove the indexing marker
configure robots.txt with Disallow: /
- default to indexing disabled
- preserve unrelated robots.txt directives where possible
- write robots.txt atomically
- report unwritable files clearly
- leave the instance in the safer non-indexable state after partial failure
Sitemap Generation¶
Add a small, explicit sitemap generator for public application resources.
The generator should support:
- explicit static routes
- application-provided URL sources
- instance URL from configuration
- optional last-modified dates
- URL normalization and deduplication
- valid XML generation
- atomic file replacement
Possible Shuttle operations:
The generator must not discover controller methods automatically, infer public access from route names or include protected resources.
Later — Operational Interfaces¶
These are interfaces over capabilities that already exist.
Ledger viewer¶
Yarn asset manager¶
asset list
preview
owner and type filters
download
visibility and status
deactivation
storage metadata
They should remain application-facing examples or optional interfaces unless repeated projects establish a stable shared contract.
Extension track¶
Data export¶
Recognize exports as a recurring capability without adding heavy core dependencies.
CSV
native PHP streaming with fputcsv()
XLSX
OpenSpout for large, simple tabular exports
PhpSpreadsheet for complex workbooks
PDF
evaluate a renderer according to the document use case
Possible shared abstractions should be extracted only after use in real applications.
API authentication¶
The API remains read-only and uses application/session protection where required.
When a machine-to-machine use case exists, Heddle may gain:
API mutation is not implied by token authentication.
Yarn image derivatives¶
A future optional integration may provide:
Image processing should remain optional until a stable cross-project contract emerges.
Deliberately not planned¶
Loom73 does not currently plan to add:
generic caching abstraction
full REST framework
ORM
general query builder
mandatory service container
JavaScript framework
CSS framework
plugin framework
theme inheritance
automatic Model exposure through the API
The installed storage/cache/ directory remains available as runtime infrastructure for applications that need local caching. Its presence does not imply a Loom73 caching API.
For ordinary deployments, begin with:
Introduce application caching only when the expensive operation and its invalidation strategy are understood.