AX Engineering Console

Profiles

A profile holds the stack assumptions that must not live in the harness core. It may supply a command for a gate the project omitted, and it records the architecture assumptions a change should preserve.

A profile may never enable a gate, relax a permission, or mark an unavailable gate as satisfied. What each one supplies, and what it deliberately does not, is read from the definition below.

  • fullstackfullstackA repository holding a backend and a frontend in separate directories, each resolved by its own profile.Experimental

    Composed areas

    • backend: backend/ resolved by java-spring, owned by backend-engineer, database-reviewer
    • frontend: frontend/ resolved by nextjs-react, owned by frontend-engineer

    Architecture assumptions

    • Each area keeps its own build system, conventions, and quality gates.
    • The API contract is the boundary; a change to it affects both areas and needs integration review.
    • A change confined to one area is ordinary single-area work and needs no coordination.
    • Determining affected areas precedes deciding which roles are involved.

    Limitations

    • Supplies no commands. A composed project must declare commands that cover both areas explicitly.
    • Area directories are fixed by this definition. A repository laid out differently needs its own profile.
    • project.build_system cannot be used with a composed profile, because there is more than one build root.
    • Composition is one level deep; an area profile must itself declare build systems.
    • Determining affected areas is path analysis only. It does not prove that an area is unaffected in behavior.
    • Multi-repository composition remains unsupported and is rejected by the project schema.
    Inspect the definition source
  • harness-toolingharness-toolingThis repository's own Node and TypeScript workspace, which hosts the vendor-neutral Harness package.Implemented

    Build systems

    • node: detected by package.json; runs via npm; supplies build, typecheck, test, security

    Architecture assumptions

    • Harness core stays vendor-neutral; stack assumptions belong to profiles and vendor instructions to adapters.
    • JSON Schema is authoritative and TypeScript types are generated from it.
    • Configuration validation and profile resolution never execute declared commands.
    • The legacy Java projects preserved in this repository are outside the npm workspace and are never built by it.

    Limitations

    • Applies to this repository's own tooling workspace, not to arbitrary Node applications.
    • No lint default is supplied, because the workspace does not define a lint command yet.
    • npm availability is assumed and never verified.
    Inspect the definition source
  • java-springjava-springJava and Spring Boot services built with Maven or Gradle. Supplies build and test command defaults; other gates must be declared by the project.Experimental

    Build systems

    • maven: detected by pom.xml; runs via wrapper or mvn; supplies build, test
    • gradle: detected by build.gradle, build.gradle.kts; runs via wrapper or gradle; supplies build, test

    Architecture assumptions

    • Controller, service, and repository or mapper layers stay separated; business logic belongs in the service layer.
    • REST endpoints expose DTOs rather than persistence entities.
    • Transaction boundaries are declared at the service layer.
    • Spring Security configuration is security-sensitive and requires explicit review.
    • SQL and schema changes are reviewed for indexes, constraints, and migration safety.
    • Unit tests and integration tests are distinct; integration tests may require external services.

    Limitations

    • A manifest is evidence of build layout only. It does not prove that Spring Boot, a specific JDK, or any plugin is present and working.
    • No integration_test default is supplied, because neither Maven failsafe nor a Gradle integrationTest task is guaranteed to be configured.
    • No lint, typecheck, or security default is supplied, because Java projects share no single standard command for them.
    • Resolution never runs a wrapper, parses a build script, or verifies that a task exists.
    • This profile has not been validated against the legacy Java projects preserved in this repository.
    Inspect the definition source
  • nextjs-reactnextjs-reactNext.js App Router and React applications on Node. Supplies only the commands such a project reliably has, which is fewer than it first appears.Experimental

    Build systems

    • node: detected by package.json; runs via npm; supplies build, security

    Detection evidence

    • next.config.js
    • next.config.mjs
    • next.config.ts

    Architecture assumptions

    • App Router routes live under app/, with route segments owning their own layout and loading states.
    • Server components are the default; a client component is an explicit, justified choice.
    • Data is fetched on the server where possible, rather than round-tripping through the client.
    • Types describe the real shape of data rather than widening to any at the boundary.
    • Accessibility and responsive behavior are part of the work, not a later cleanup.
    • API contracts are owned by the backend; the client adapts to them rather than the reverse.

    Limitations

    • A package.json proves a Node layout only. It does not prove that Next.js, React, or TypeScript are installed.
    • Confirmation reads declared dependency names and looks for a Next.js config file. A declared dependency is not an installed one, and a project that vendors its dependencies differently will go unconfirmed and must be chosen explicitly.
    • No lint default is supplied, because a Next.js project may use ESLint, Biome, or no linter at all.
    • No typecheck default is supplied, because create-next-app scaffolds no typecheck script. Projects that type-check in CI usually need next typegen before tsc --noEmit, since route types are otherwise only generated during dev or build.
    • No test or integration-test default is supplied. No test runner is scaffolded, and Playwright is never assumed to be present.
    • next lint is not used. It is absent from the current Next.js CLI, so linting is left to the project's own script.
    • Resolution never runs a script, reads package.json contents, or verifies that a declared script exists.
    Inspect the definition source