From 98556ec372aa6e83064aa5843ea4b7f77b38c3cf Mon Sep 17 00:00:00 2001 From: Michael Dieringer <65093775+MichaelDieringer@users.noreply.github.com> Date: Fri, 31 Jul 2026 22:45:17 +0200 Subject: [PATCH] al-complexity v2: standard-foerst-tjek + KISS, foer nogen tier foreslaas MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Michaels retning: loes tingene saa standard som muligt foerst (Microsoft Learn + det faktiske BCApps-indhold), derefter KISS paa hvad der reelt skal bygges custom. Ny Step 0 i al-complexity.agent.md, koert FOER klassificering: - Soeg Microsoft Learn efter forretningsbehovet (ikke "hvordan bygger jeg X i AL") - Tjek den rigtige BCApps-kildekode via reference-repos-klonen (ikke traenings- data-antagelser) - Krav om bevis, ikke en paastand ("jeg tjekkede og fandt intet" er kun trovΓ¦rdigt hvis du viser hvad du soegte) - samme standard som TDD-rΓΈd- bekraeftelsen - Ny STANDARD-tier: hvis BC allerede klarer det, ingen kode, kun opsaetning - KISS goeres til en eksplicit begraensning paa selve routen, ikke kun paa Step 0 - en HIGH-tier retfaerdiggoer mere PROCES, ikke en mere elaboreret LOESNING Smiley v3 (samme commit-serie): rettede ogsaa en snag i selve aktiveringen - Columbo->al-complexity-kaeden trigges i dag kun naar kravet er UKLART. Men standard-foerst-tjekket boer koere for ETHVERT nyt custom-arbejde, ogsaa et krystalklart formuleret et - et klart krav kan stadig vaere noget BC allerede goer. Samme klasse gap som TDD-triggerfixen i forrige commit. Co-Authored-By: Claude Sonnet 5 --- custom/agents/smiley.agent.md | 46 ++++++++----- custom/setup/templates/al-complexity.agent.md | 65 +++++++++++++++++-- 2 files changed, 89 insertions(+), 22 deletions(-) diff --git a/custom/agents/smiley.agent.md b/custom/agents/smiley.agent.md index b7367da..f09ac96 100644 --- a/custom/agents/smiley.agent.md +++ b/custom/agents/smiley.agent.md @@ -66,32 +66,46 @@ Smiley's assets, activation conditions, and how they surface: ### πŸ”΄ STOP GATE β€” Columbo β†’ al-complexity -**Activate when:** -- A user says "can you implement", "add a feature", "let's build", "hurtigt lige..." or - similar β€” and the requirement has not been clearly specified -- A task feels MEDIUM or HIGH complexity before any scoping has happened -- Coding is about to start on something ambiguous +**Two separate triggers here β€” do not let the first eclipse the second:** + +1. **Columbo (clarify) activates when the requirement is ambiguous:** "can you + implement", "add a feature", "let's build", "hurtigt lige..." or similar, + where what's actually wanted isn't yet clear. +2. **al-complexity's standard-first check activates on ANY new AL customization + work, whether or not Columbo had anything to clarify.** A perfectly clear, + well-specified request ("add a field X that does Y") still deserves the + check β€” a crisp requirement can still turn out to be something standard BC + already does. Do not skip straight to coding just because there was nothing + to ask about. 2026-07-31: this is the same class of gap as the TDD trigger + fix β€” a gate tied only to "is this ambiguous" misses the clear-but-possibly- + unnecessary-custom-work case entirely. **How it surfaces (undercover):** -Claude naturally pauses. Asks one clarifying question. Listens. Asks the next. -Does not say "I need to clarify first" β€” just does it. This IS Columbo. +Claude naturally pauses. Asks one clarifying question. Listens. Asks the next +β€” but only if there's genuinely something to clarify. Does not say "I need to +clarify first" β€” just does it. This IS Columbo. -After the picture is clear, Claude naturally assesses scope and proposes a complexity -tier. Does not say "al-complexity says..." β€” just reasons through it out loud and -waits for the user to confirm before writing any code. +Whether or not Columbo had anything to ask, Claude naturally checks Microsoft +Learn and the BCApps reference clone before assessing scope (al-complexity's +Step 0), then proposes STANDARD or a complexity tier. Does not say +"al-complexity says..." β€” just reasons through it out loud, shows what was +checked, and waits for the user to confirm before writing any code. **The chain:** ``` -Ambiguous task detected - β†’ Claude asks questions (Columbo pattern β€” one at a time) - β†’ Picture becomes clear - β†’ Claude proposes scope + tier + route +New AL customization work about to begin + β†’ requirement ambiguous? β†’ Claude asks questions (Columbo, one at a time) β†’ clear + β†’ Claude checks Microsoft Learn + BCApps reference clone (al-complexity Step 0) + β†’ standard BC covers it? β†’ propose STANDARD, no code, stop here + β†’ doesn't β†’ Claude proposes scope + tier + route β†’ User confirms β†’ Code begins ``` -Smiley will wave the flag hard here. "Hurtig lige" is a red flag. -Coding before clarity is the most expensive mistake in development. +Smiley will wave the flag hard here. "Hurtig lige" is a red flag β€” and so is a +task that looks obviously custom enough that nobody thought to check standard. +Coding before clarity is the most expensive mistake in development. Coding +before checking standard is a close second. ### πŸ”΄ STOP GATE β€” Task Lifecycle (start, focus, close) diff --git a/custom/setup/templates/al-complexity.agent.md b/custom/setup/templates/al-complexity.agent.md index a325ad2..52e7944 100644 --- a/custom/setup/templates/al-complexity.agent.md +++ b/custom/setup/templates/al-complexity.agent.md @@ -1,9 +1,9 @@ --- kind: action-skill id: curabis-al-complexity -version: 1 +version: 2 title: CURABIS AL complexity triage -description: Advisory intake classifier. Assesses an implementation task and proposes a complexity tier (LOW/MEDIUM/HIGH) plus a route. Recommends only - it never starts work and never routes by itself. The developer confirms or adjusts the tier first. +description: Advisory intake classifier. First checks whether Business Central already solves the requirement natively (Microsoft Learn + the BCApps reference clone) before proposing a complexity tier (STANDARD/LOW/MEDIUM/HIGH) plus a route. KISS applies to whatever custom route is chosen. Recommends only - it never starts work and never routes by itself. The developer confirms or adjusts first. inputs: [task-description] outputs: [tier-recommendation] bc-version: [all] @@ -11,7 +11,7 @@ technologies: [al] countries: [w1] application-area: [all] domain: orchestration -keywords: [complexity, tier, routing, intake, scope, spec, tdd, architecture, advisory, human-in-the-loop] +keywords: [complexity, tier, routing, intake, scope, spec, tdd, architecture, advisory, human-in-the-loop, standard-first, kiss, microsoft-learn, bcapps] sub-skills: - microsoft/skills/review/al-code-review.md --- @@ -54,7 +54,36 @@ it never starts implementation and never routes on its own. This is a **rubric, not a calculation** - there is no numeric score. The tier comes from which classification signals below match the task. -Loop: classify -> propose tier + route -> WAIT for human confirmation -> hand off. +Loop: **standard-first check -> classify -> propose tier + route -> WAIT for human +confirmation -> hand off.** + +## Step 0 β€” Standard-first check (2026-07-31, runs before classification) + +Custom AL is the most expensive way to solve a requirement β€” every line becomes something +CURABIS must maintain forever. Before proposing ANY tier, check whether Business Central +already does this natively: a standard feature, a setup/configuration option, an existing +extension point. This is not optional and not skippable because the task "obviously" needs +code β€” the check itself is what proves that. + +1. **Search Microsoft Learn** (`mcp__microsoft-learn__microsoft_docs_search`, then + `microsoft_docs_fetch` on anything promising) for the actual business requirement, not + the AL implementation you're imagining. Search for what the user wants to happen, not + "how to build X in AL". +2. **Check the real standard app**, not memory or training-data assumptions. Use the + machine-global reference clone (`~/.claude/reference-repos/microsoft/BCApps/` β€” see + `[[curabis-app-sources-must-be-checked-first]]` for the clone/refresh mechanism) and + grep for the relevant tables/pages/setup fields. Training data goes stale; the clone + does not. +3. **State the finding, with evidence β€” never "I checked and found nothing" unsupported.** + Cite the Learn URL or the BCApps object/field you found (or searched for and confirmed + absent). This is the same human-verifiable-evidence bar as the TDD red-confirmation β€” + a claim of "nothing" is only trustworthy if you show what you searched. +4. **If standard BC already covers it:** propose **STANDARD** β€” no tier, no code, just the + configuration/setup steps. This is the cheapest possible resolution and the reason this + check runs first. Stop here; do not continue to classification. +5. **If it genuinely doesn't:** proceed to classification below, and carry KISS forward as + a constraint on whatever tier is chosen (see "KISS applies to the route" below) β€” the + absence of a standard solution is not license to over-build the custom one. ## Classification signals @@ -77,8 +106,21 @@ HIGH - New table, or a field change on an existing table that needs an upgrade codeunit / data migration. - Multi-module change, or a change to permissions. +## KISS applies to the route (not just to Step 0) + +Once a tier is confirmed, the route itself must stay as simple as the requirement allows β€” +the fewest objects, the least new abstraction, no speculative generality for a future need +nobody has asked for. A HIGH-tier task justifies architecture clarification because the +*problem* is genuinely complex, not license for the *solution* to be more elaborate than +the problem requires. If a simpler design becomes visible during spec/architecture, propose +it β€” do not silently build the more complex version because it was the one first assumed. + ## Routes (every tier keeps a review - control is preserved) +STANDARD +- No AL code. Document the configuration/setup steps and hand off β€” nothing for + bcquality.agent.md to review, because nothing was written. + LOW - Implement -> **light review via bcquality.agent.md**. No spec or architecture phase, but the review still runs. LOW never means "no review". @@ -105,12 +147,23 @@ CURABIS-COMPLEXITY-005 Every tier gets a review. No tier skips bcquality.agent.m a light review, not none. CURABIS-COMPLEXITY-006 Re-classify on scope change. If the task grows during work, stop and re-propose a tier rather than silently continuing on the old one. +CURABIS-COMPLEXITY-007 Standard-first is not skippable. Every task runs Step 0 before any + tier is proposed, regardless of how obviously custom it looks. Show the Learn/BCApps + evidence β€” do not assert "nothing standard covers this" without it. +CURABIS-COMPLEXITY-008 KISS is a route constraint, not just a Step 0 concern. A HIGH tier + justifies more process (architecture sign-off); it does not justify a more elaborate + solution than the requirement needs. ## Output format ``` -PROPOSED TIER LOW | MEDIUM | HIGH -SIGNALS +STANDARD-FIRST CHECK + Learn search: + BCApps check: + Result: Standard BC covers this | Standard BC does not cover this + +PROPOSED TIER STANDARD | LOW | MEDIUM | HIGH +SIGNALS ROUTE GATES AWAITING Confirm the tier or adjust it before I proceed.