Constant Field Values

Contents

ch.so.*

  • ch.so.agi.mcp.knowledge.ConstraintWorkflowGuidance
    Modifier and Type
    Constant Field
    Value
    public static final String
    TEXT
    "\nProsa zu Constraints: verbindlicher Agentenablauf\n1. Original- und Teilanforderungen erhalten; Zielkontext mit analyzeIliModel(contextFqn)\n pr\u00fcfen. Betroffene Objekte, Bedingung, Konsequenz, Grenzen und Geltungsbereich festhalten.\n Bei bekanntem Ziel-FQN fehlende Pfade mit findConstraintPaths suchen; Alternativen,\n Kardinalit\u00e4ten und Optionalit\u00e4t beurteilen. usageHints.expression als Baustein verwenden,\n dann Ausdruck erstellen und mit Authoring/Validator pr\u00fcfen. Suchgrenzen sind kein\n Unerreichbarkeitsbeweis; bekannte Pfade mit resolveConstraintPath pr\u00fcfen.\n Eindeutige Vorgaben direkt umsetzen, nur fachlich wirksame Mehrdeutigkeiten r\u00fcckfragen:\n \u201eWenn A, dann B\u201c verlangt keine Umkehrung; \u201emindestens 18\u201c schliesst 18 ein.\n Bei fehlenden Werten: unzul\u00e4ssig oder nicht anwendbar? Leere Beziehungen verlangen\n nicht automatisch ein Ziel; leere Summen nicht ungepr\u00fcft als Null behandeln.\n \u201eeindeutig\u201c ben\u00f6tigt GLOBAL, BASKET oder LOCAL als fachlich begr\u00fcndeten Bereich.\n2. VOR Authoring zul\u00e4ssige, unzul\u00e4ssige, Grenz- und notwendige Fehlwertf\u00e4lle festhalten.\n expectationSource: USER_PROVIDED, USER_CONFIRMED, AGENT_DERIVED oder UNSPECIFIED.\n Herkunft ist nicht serverseitig verifiziert. Erwartungen nicht aus dem fertigen\n Constraint ableiten oder nach Fehlern passend \u00e4ndern. Fehlende Gegenf\u00e4lle nicht erfinden.\n3. Typisierte Authoring-Tools nutzen; zusammengeh\u00f6rende \u00c4nderungen als atomaren Batch.\n Normal includeSuccessfulTestXtf=false w\u00e4hlen: nur erfolgreiche, warnungsfreie Transfers\n entfallen. omittedSuccessfulTestXtfCount nennt die Anzahl; Befunde bleiben vollst\u00e4ndig.\n Vollst\u00e4ndige Ausgabe nur bei konkretem Diagnosebedarf anfordern, nicht routinem\u00e4ssig.\n4. Ergebnisse anhand bestehender Felder behandeln:\n INVALID_SPEC: mit specDiagnostics genau das betroffene Feld einmal korrigieren,\n ohne Fachsemantik zu \u00e4ndern; strengere Versuchslimits gelten.\n Vorgelagerte MCP-Schemafehler sind kein Serverstatus INVALID_SPEC und d\u00fcrfen weder\n im Protokoll noch in der Bewertung so umetikettiert werden; sie erweitern das Versuchslimit nicht.\n NEEDS_INPUT/offene Fachfragen: fehlende Entscheidung einholen.\n Compilerfehler: konkrete Diagnose bearbeiten, keinen unver\u00e4nderten Aufruf wiederholen.\n PROOF_INCOMPLETE/PROOF_FAILED: Grenze berichten, Kandidaten nicht freigeben.\n5. Nach erfolgreichem Authoring die vorab festgehaltenen F\u00e4lle mit testIliConstraint pr\u00fcfen.\n Das ist zus\u00e4tzlich zum automatischen Proof erforderlich. modelHashes.model des Tests\n muss modelHashes.after des Authorings entsprechen. Offene Fachentscheide, fehlgeschlagene\n oder nicht ausf\u00fchrbare notwendige Tests, ung\u00fcltige Fixtures oder nicht ausge\u00fcbte Regeln\n verhindern das Schreiben. Ein erfolgreicher Serverstatus allein erlaubt kein Schreiben.\n6. Vor \u00dcberschreiben die aktuelle Datei erneut lesen und ihren SHA-256 \u00fcber den exakten\n UTF-8-Text mit modelHashes.before vergleichen. Bei Abweichung vom aktuellen Stand neu\n ansetzen, nicht automatisch zusammenf\u00fchren. Zeilenenden und Unicode nicht normalisieren.\n Hashes identifizieren Text, keine Importe oder Validatorumgebung; keine atomare Dateisperre.\n7. explanation und entscheidende F\u00e4lle zeigen; PARTIAL/UNAVAILABLE sowie\n CONTRADICTION_PROVEN und andere relevante Interaktionsgrenzen sichtbar berichten.\n constraintInteractions bleiben advisory; technische Statuswerte und Freigaben unver\u00e4ndert.\n Bei requiresUserDecision=true die konkrete Frage und den Umgang damit in der\n Abschlussantwort nennen. Ist eine allgemeine Frage anhand des vorhandenen Auftrags\n f\u00fcr die konkrete \u00c4nderung unerheblich, diese Beurteilung dort begr\u00fcnden; das Flag\n bleibt unver\u00e4ndert. Kein Modellzweck wird erfunden, keine pauschale Ausnahme erteilt.\n Tats\u00e4chlich offene Fachentscheide verhindern weiterhin das Schreiben; Proofs ersetzen\n diese Beurteilung nicht.\n\nEinzeltests isolieren den Constraint; AGENT_DERIVED ist keine unabh\u00e4ngige Fachabnahme,\nbusinessAcceptance bleibt NOT_RUN. Der Server erzwingt die Schreibregel nicht bei fremden\nClients. Diesen Ablauf bei Prosa-Authoring anwenden, nicht bei reinen Reviews.\n"
    public static final String
    TOOL
    " Prosa: Erwartungen vorab festhalten, vor Schreiben mit testIliConstraint pr\u00fcfen. Test-modelHashes.model muss Authoring-modelHashes.after entsprechen; aktuelle Datei gegen before pr\u00fcfen. Normal includeSuccessfulTestXtf=false. INVALID_SPEC gezielt einmal korrigieren; offene Fragen kl\u00e4ren, Proof-Grenzen berichten. Serverstatus allein ist keine Schreibfreigabe."
  • ch.so.agi.mcp.model.ConstraintAuthoringGuidance
    Modifier and Type
    Constant Field
    Value
    public static final String
    COUNT
    "OBJECT_COUNT als Ausdruck liefert eine Zahl: {\"kind\":\"COMPARE\",\"operator\":\"==\",\"children\":[{\"kind\":\"OBJECT_COUNT\",\"objects\":{\"kind\":\"ALL\"}},{\"kind\":\"NUMERIC\",\"value\":1}]}. Nur die separate SET-Condition OBJECT_COUNT hat objects, operator und threshold; sie hat kein value."
    public static final String
    ENUM
    "ENUM.value ist ein String, z.B. Drainage oder #Drainage, auch Gruppe.Drainage. Genau ein optionales fuehrendes # wird normalisiert; TEXT/MTEXT bleiben unveraendert."
    public static final String
    FUNCTION
    "FUNCTION: name ist bei functionOrigin=STANDARD die semanticId aus listConstraintFunctions, z.B. COLLECTION_SUM statt Math.sum und NUMERIC_ADD statt Math.add. Bei MODEL/VALIDATOR_EXTENSION ist name der qualifizierte Funktionsname. Argumente stehen ausschliesslich geordnet in children, niemals in FUNCTION.objects."
    public static final String
    INPUT
    " Prosa: Erwartungen vorab festhalten, vor Schreiben mit testIliConstraint pr\u00fcfen. Test-modelHashes.model muss Authoring-modelHashes.after entsprechen; aktuelle Datei gegen before pr\u00fcfen. Normal includeSuccessfulTestXtf=false. INVALID_SPEC gezielt einmal korrigieren; offene Fragen kl\u00e4ren, Proof-Grenzen berichten. Serverstatus allein ist keine Schreibfreigabe. Technischer Constraint-Name: [A-Za-z][A-Za-z0-9_]*, z.B. Regel42. Eine fachliche Regelnummer ist kein technischer Name; keine automatische Umbenennung. ENUM.value ist ein String, z.B. Drainage oder #Drainage, auch Gruppe.Drainage. Genau ein optionales fuehrendes # wird normalisiert; TEXT/MTEXT bleiben unveraendert. FUNCTION: name ist bei functionOrigin=STANDARD die semanticId aus listConstraintFunctions, z.B. COLLECTION_SUM statt Math.sum und NUMERIC_ADD statt Math.add. Bei MODEL/VALIDATOR_EXTENSION ist name der qualifizierte Funktionsname. Argumente stehen ausschliesslich geordnet in children, niemals in FUNCTION.objects. OBJECT_COUNT als Ausdruck liefert eine Zahl: {\"kind\":\"COMPARE\",\"operator\":\"==\",\"children\":[{\"kind\":\"OBJECT_COUNT\",\"objects\":{\"kind\":\"ALL\"}},{\"kind\":\"NUMERIC\",\"value\":1}]}. Nur die separate SET-Condition OBJECT_COUNT hat objects, operator und threshold; sie hat kein value. Ergebnis evidence trennt ausgef\u00fchrte Pr\u00fcfungen von fachlicher Akzeptanz; neue Befunde \u00e4ndern keine Freigaben."
    public static final String
    MANDATORY_INPUT
    "MANDATORY: Der Ausdruck steht in spec.condition; Operanden stehen geordnet in children. Beispiel fuer spec bei vorhandenem Attribut value: {\"kind\":\"MANDATORY\",\"name\":\"ValueRequired\",\"condition\":{\"kind\":\"DEFINED\",\"children\":[{\"kind\":\"ATTRIBUTE\",\"name\":\"value\"}]}} Skalare Ausdruecke: Zahlen als {\"kind\":\"NUMERIC\",\"value\":7}; COMPARE mit operator ==, !=, <, <=, > oder >= und genau zwei geordneten children. DEFINED/NOT haben ein Kind, IMPLIES zwei; AND/OR behalten die Reihenfolge. MANDATORY verwendet condition."
    public static final String
    MANDATORY_SPEC_EXAMPLE
    "{\"kind\":\"MANDATORY\",\"name\":\"ValueRequired\",\"condition\":{\"kind\":\"DEFINED\",\"children\":[{\"kind\":\"ATTRIBUTE\",\"name\":\"value\"}]}}"
    public static final String
    NAME
    "Technischer Constraint-Name: [A-Za-z][A-Za-z0-9_]*, z.B. Regel42. Eine fachliche Regelnummer ist kein technischer Name; keine automatische Umbenennung."
    public static final String
    SCALAR_INPUT
    "Skalare Ausdruecke: Zahlen als {\"kind\":\"NUMERIC\",\"value\":7}; COMPARE mit operator ==, !=, <, <=, > oder >= und genau zwei geordneten children. DEFINED/NOT haben ein Kind, IMPLIES zwei; AND/OR behalten die Reihenfolge. MANDATORY verwendet condition."
  • ch.so.agi.mcp.model.ConstraintSpecContract
    Modifier and Type
    Constant Field
    Value
    public static final String
    IDENTIFIER
    "[A-Za-z][A-Za-z0-9_]*"
    public static final String
    SEMANTIC_PATH
    "[A-Za-z][A-Za-z0-9_]*(?:(?:\\.|->)[A-Za-z][A-Za-z0-9_]*)*"
  • ch.so.agi.mcp.model.EnumLiteralValue
    Modifier and Type
    Constant Field
    Value
    public static final String
    PATTERN
    "[A-Za-z][A-Za-z0-9_]*(?:\\.[A-Za-z][A-Za-z0-9_]*)*"
  • ch.so.agi.mcp.model.TestXtfOutput
    Modifier and Type
    Constant Field
    Value
    public static final String
    PARAMETER
    "Standard true. false l\u00e4sst nur XTF-Texte bestandener, ausge\u00fcbter F\u00e4lle mit g\u00fcltiger Fixture und null Warnungen weg; alle Diagnosen bleiben erhalten."