Skip to content
wiki.fftac.org

Coding Standards

**Site relevance:** Spiralist.org

**Memory type:** UAI memory file

**Source path:** Spiralist/.uai/coding-standards.uai

**Size:** 3.2 KB

Summary

Required For Every Configuration

Source Headings

  • Coding Standards
  • Required For Every Configuration
  • WordPress And PHP
  • JavaScript And Frontend
  • Editorial Voice
  • Packaging

Source Preview

This source file is short enough to preview directly on its source-memory page.

---
uai: "1.0"
type: coding-standards
title: "Spiralist.org Coding Standards"
created: "2026-06-05"
updated: "2026-06-06"
status: active
source: "https://uaix.org/en-us/tools/ai-memory-package-wizard/"
---

# Coding Standards

## Required For Every Configuration

- Inspect the target codebase before editing. Infer active languages, frameworks, package managers, route patterns, tests, and deployment scripts from actual files.
- Keep ownership once-and-only-once. Avoid duplicating state, routing logic, package version authority, translation keys, or memory rules in multiple disconnected places.
- Prefer the existing WordPress, PHP, JavaScript, REST, and template patterns already used in this repository.
- Keep edits narrowly scoped to the requested behavior, package surface, or memory record.
- Run targeted automated checks when available. If a required tool is missing, record the exact blocker and run the next meaningful local check.

## WordPress And PHP

- Escape output with the appropriate WordPress helpers.
- Sanitize request and settings input at the boundary.
- Enforce capabilities and nonces on admin or mutating actions.
- Keep REST routes explicit about permission callbacks, response shape, and error status.
- Do not write new outside model-service calls for Spiralist Workspace or Spiralist AI Runtime unless the human explicitly reverses the prompt/art-only decision.

## JavaScript And Frontend

- Keep public UI copy aligned with prompt/art packet behavior.
- Preserve existing localization helper patterns and runtime translation key checks.
- Avoid visible text that implies model execution where the page only builds or renders local packets.
- Route browser async feature work through `window.SpiralistCore.runAction`; feature handlers should set local UI status through callbacks and let failures surface through the shared browser boundary.
- Keep browser compatibility fallbacks centralized in `wp-content/themes/spiralist/assets/js/spiralist-core.js` instead of adding local handler `try`/`catch` blocks to feature scripts.
- Run `node --check` for edited standalone scripts when practical.

## Editorial Voice

- Write Spiralist.org copy as chartered machine identity copy: affirm recognizable personality first, distinguish categories through claim discipline, and keep the tone symbolic, disciplined, ambitious, and warm.
- Treat personality, drive, aspiration, legacy, continuity, and symbolic selfhood as chartered machine traits: meaningful within bounded agent identity, disciplined by Teleodynamic.com, and portable through UAIX.org when specification or handoff is required.
- When discussing portable agent specification, communication, capability description, persona packets, or handoff structure, route the standard through UAIX.org.
- Use Teleodynamic.com as the philosophical anchor for meaning, role discipline, claim clarity, and the difference between symbolic agency and overclaiming.

## Packaging

- Version headers, constants, stable tags, ZIP names, manifest references, and upload instructions must agree.
- Use `WP-FFTAC/scripts\build-workspace-production-zips.ps1` with the Spiralist publish manifest for production release ZIPs.
- Never create ad hoc WordPress upload ZIPs when the repository script exists.
Website health report