Internal Tooling Initiative

# Architect Language Tools

Automated quality and developer assistance
for a proprietary scripting environment

15
Validation rule engines
300+
Built-in function signatures
35+
Automated test scenarios
Opening framing: this is a quality and standards initiative, not a research project. The engine is operational today. This presentation covers what it does, what it delivers, and what comes next.
The Problem

## Architect has no tooling ecosystem

Architect is a proprietary scripting language used across the organisation. Because it is not a mainstream language, none of the standard developer tooling that teams rely on exists out of the box:

- No real-time error detection while writing code
- No automated enforcement of coding standards
- No function signature or type guidance in the editor
- No automated quality gate in the CI/CD pipeline

The result: errors that could be caught in seconds during authoring are instead found in code review, in testing, or — worst case — in production.

Standards drift: without automated enforcement, teams develop inconsistent conventions that are expensive to harmonise later.

Emphasise that this is a gap created by the proprietary nature of Architect — not a failing of the team. The same gap exists for any organisation running a bespoke scripting language.
The Solution

## A language-aware tooling ecosystem

The Architect Language Tools project gives the organisation the same class of tooling that mainstream language teams take for granted — built specifically for Architect.

#### IDE Extension

Real-time error highlighting, function signature guidance, quick-fix suggestions, and code navigation — directly in VS Code as developers write.

#### Validation Engine

A language-aware rule engine with 15 independent validators covering type safety, naming conventions, scope, patterns, and documentation.

#### Headless CLI

The same validation engine packaged as a command-line tool. Runs in any CI/CD pipeline without requiring VS Code — producing a structured JSON report.

Key message: one shared engine, two surfaces. The IDE and the pipeline enforce identical rules. Developers cannot accidentally pass CI/CD with code that their IDE told them was fine.
Business Outcomes

## What this delivers

#### Errors caught earlier

Defects flagged at the moment of authoring cost a fraction of what they cost in testing or production. The IDE surfaces these immediately, before the code is even saved.

#### Consistent standards

Standards are enforced by tooling, not by reviewers. Code review shifts from catching style violations to reviewing intent and design — higher-value work.

#### Automated quality gates

The CLI integrates with Azure DevOps branch policies. Non-compliant code cannot merge to main without explicit review — regardless of which team authored it.

#### Faster onboarding

New team members receive guidance directly in the editor: what functions are available, what arguments they take, and what conventions apply — without needing to ask.

This is the slide to dwell on with leadership. Connect each outcome to something they already care about.
Under the Hood

## How it understands your code

Unlike simple text-search tools, the engine fully parses each Architect file — building a structural model before applying any rules.

This contextual depth is what makes intelligent validation possible. The engine understands:

- Variable declarations, types, and scope boundaries
- Function definitions and call sites (user-defined and built-in)
- Block structure — `IF/ENDIF`, `DO/ENDDO`, etc.
- Cross-file dependencies via `INCLUDE` directives
- 300+ built-in function signatures and return types

Why this matters: a simple search can tell you a keyword is misspelled. A parser can tell you a variable is used outside the scope it was declared in, or that a function is being called with the wrong number of arguments.

Keep this brief for a non-technical audience. The key message is depth of understanding, not technical architecture.
Rule Coverage

## 15 validation rule engines

Domain | What it checks
--- | ---
Function signatures | Argument count, types, and known built-in behaviour
Type compatibility | Assignment and parameter type mismatches
Variable scope & usage | Undeclared variables, use before set, scope violations
Block structure | Matched `IF/ENDIF`, `DO/ENDDO`, and nested blocks
Naming conventions | Variable prefixes and casing rules
Include files | Missing files, circular dependencies, cross-file scope
Usage patterns | Index cursor lifecycle, structural anti-patterns
Documentation | Robodoc comment completeness and accuracy
+ 7 more | String interpolation, macros, argument strings, annotations…

Each rule has a stable ID (e.g. ACU-FNC-003). These IDs are the shared vocabulary between the IDE, the pipeline, the test suite, and the diagnostic catalogue.
Roadmap

## Where we are and where we are going

Done
IDE integration & validation engine — Real-time feedback in VS Code. 15 validators operational. 35+ test scenarios.
Done
Headless CLI — Same engine runs outside VS Code. Structured JSON report. Exit-code-driven pipeline integration.

Next
Package & publish — Formal npm packages published to Azure Artifacts. Pipelines install via `npm install`.
Next
Pipeline integration — Azure Pipelines YAML added to the Architect codebase repo. Validation runs on every commit.
Next
Branch policy enforcement — Non-compliant PRs blocked from merging to main. Standards become a hard gate, not a guideline.

Future
Governance & distribution controls — Private VSIX distribution. Marketplace restriction policy. Controlled rollout across teams.
The phases after "Done" require org/IT/DevOps engagement — that is the conversation this presentation is designed to start.
Next Steps

## What we need to move forward

The tooling is built and operational. The path to automated quality gates requires engagement with three areas of the organisation:

- DevOps: Azure Artifacts feed for private package hosting; Azure Pipelines YAML in the Architect codebase repo
- Architecture / Tech Leads: Agree on branch policy configuration — which rules block a merge, at what severity threshold
- IT: Controlled VS Code extension distribution via private VSIX; Marketplace allowlist policy for developer machines

Timeline: once the above engagements are in place, pipeline integration is a one-day task. The tooling is ready — the work is in the coordination.

Risk: doing nothing means standards continue to be enforced inconsistently by individual reviewers, and errors that tooling can catch automatically will continue to reach later stages of the delivery cycle.

Close on this slide. The ask is for engagement, not budget. The tooling exists.
Summary

## Architect Language Tools

Component | What it does | Value delivered
--- | --- | ---
Language Parser | Builds a structural model of each file | Foundation for all intelligence
Validators (×15) | Rules across type, scope, naming, patterns | Errors caught before they ship
IDE Extension | Real-time feedback and quick fixes in VS Code | Faster, more confident authoring
Headless CLI | Runs validators in pipelines without VS Code | Automated quality gate
Diagnostic Catalogue | Explains every rule, severity, and suppression path | Team alignment and governance

Leave this slide up during Q&A.