Work Classifier
The work classifier determines the domain of a Work Unit using weighted signals from code paths, lane names, WU type, and description keywords. It returns abstract capability tags and test methodology hints for vendor-agnostic integration.
Framework-specific file conventions are treated as optional signals, not baseline truth. LumenFlow ships generic UI patterns such as stylesheets, components/, and pages/; if your repo relies on framework-specific directories such as Next.js app-router files, declare them through methodology.work_classification.ui.code_path_patterns.
classifyWork(doc, config?)
Section titled “classifyWork(doc, config?)”Classify the work domain from multiple weighted signals.
Parameters:
| Parameter | Type | Description |
|---|---|---|
doc | object | WU document with code_paths, lane, type, description |
config | WorkClassificationConfig | Optional config to extend default patterns |
Returns: WorkClassification
WorkClassification
Section titled “WorkClassification”WorkSignal
Section titled “WorkSignal”Signal Weights
Section titled “Signal Weights”| Signal | Weight | Description |
|---|---|---|
code_paths | 1.0 | Glob pattern matching against file paths |
lane | 0.6 | Lane parent/sublane name matching |
type | 0.3 | WU type field (e.g., documentation) |
description | 0.2 | Keyword matching in description text |
Confidence = max(matched signal weights), not sum. Domain is assigned only when confidence >= 0.3.
Constants
Section titled “Constants”WORK_DOMAINS
Section titled “WORK_DOMAINS”SIGNAL_WEIGHTS
Section titled “SIGNAL_WEIGHTS”DEFAULT_UI_CODE_PATH_PATTERNS
Section titled “DEFAULT_UI_CODE_PATH_PATTERNS”Built-in glob patterns for detecting UI work via code paths:
**/*.css,**/*.scss,**/*.less**/*.module.css,**/*.module.scss**/*.styled.ts,**/*.styled.tsx**/components/**,**/pages/**
Next.js app-router patterns are intentionally not built into the default list. Add them via config when a workspace actually uses them.
DEFAULT_UI_LANE_HINTS
Section titled “DEFAULT_UI_LANE_HINTS”Built-in lane parent hints: Experience, Frontend, UI, Design.
Capabilities
Section titled “Capabilities”The classifier returns abstract capability tags (not client-specific skill names):
| Domain | Capabilities |
|---|---|
ui | ui-design-awareness, component-reuse-check |
docs | documentation-structure, link-validation |
infra | infrastructure-review, security-check |
mixed | cross-domain-awareness |
backend | (none) |
Configuration
Section titled “Configuration”Extend default patterns via methodology.work_classification in workspace.yaml.
Custom values extend the built-in defaults; they do not replace them.
WorkClassificationConfig
Section titled “WorkClassificationConfig”Test Methodology Hint
Section titled “Test Methodology Hint”The classifier emits methodology hints as recommendations for prompt composition. They are not a hardcoded software-engineering mandate.
smoke-test
Section titled “smoke-test”When the detected domain is ui and confidence >= 0.5, the classifier returns
testMethodologyHint: 'smoke-test'. The default wu:brief composition uses this to prefer
integration, E2E, smoke, and manual verification for UI work, while reserving unit tests for pure
logic or explicitly required verification.
structured-content
Section titled “structured-content”When every declared code path is structured content (.yaml, .yml, .json, .md, .mdx),
the classifier returns testMethodologyHint: 'structured-content'. The default wu:brief
composition uses this to prefer parsing, linting, schema, evaluator, and smoke evidence instead of
forcing backend-style TDD.
Brief Integration
Section titled “Brief Integration”The work classifier is wired into wu:brief generation (WU-1900) at four points:
Capability-to-Skill Mapping
Section titled “Capability-to-Skill Mapping”Capabilities are mapped to client-specific skills via capabilities_map in client config:
When classifier capabilities match keys in the map, the corresponding skill names appear in the brief’s Soft Policy section. This keeps the classifier vendor-agnostic while allowing each client to define its own skill names.
Design Context Section
Section titled “Design Context Section”A ## Design Context section is added to the brief for UI-classified work, with guidance on pattern checks, viewport verification, and accessibility. This section contains no /skill syntax or client-specific names.
Template Selection
Section titled “Template Selection”The classifier also feeds prompt-template conditions such as work.domain and
work.testMethodologyHint. The built-in defaults use those fields to include sections like
visual-directive, structured-content-directive, and design-context-ui.
Conditional Constraints
Section titled “Conditional Constraints”The constraints block’s TDD CHECKPOINT is omitted when work is classified as UI domain or methodology is none.