#dalsza pomoc w debugowaniu skilla

1 messages · Page 1 of 1 (latest)

tight adderBOT Feb 11, 2026, 12:10 PM

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

lusty pilotBOT Feb 11, 2026, 12:13 PM

Pewnie — przejrzałem gista i kontekst (Twój „self‑improver”, slug/taxonomy, merge zamiast append, TTL hotfixów itd.). Poniżej masz Handoff Lint (v1): gotowy, „wklejalny” moduł jakości, który możesz odpalać na końcu nocnego joba (albo po każdym większym kroku), żeby zanim cokolwiek zapiszesz/promujesz, sprawdzić że wynik jest spójny, deterministyczny i nie produkuje bloatu.

1) Co to jest “Handoff Lint” i gdzie go wpiąć

Cel: zanim skill zrobi “handoff” (czyli: zapisze zmiany do .learnings/, zmerguje reguły, zaktualizuje AGENTS/TOOLS/SOUL albo wygeneruje raport), ma przejść przez zestaw testów:

safety (brak destrukcji / brak wycieku)
determinism (JSON-only tam gdzie trzeba, idempotent)
anti-bloat (one-rule-per-slug, budżety, merge > append)
evidence (promocja tylko gdy są twarde sygnały)
TTL hygiene (hotfixy wygasają)
scope (global vs local preferencje)

Wpięcie: ostatni krok nocnego review:

bucket/cluster → 2) LLM merge (JSON) → 3) plan operacji → 4) aplikacja zmian → 5) HANDOFF_LINT → 6) dopiero wtedy zapis/promocja + raport

Jeśli lint zwraca fail → job nie promuje i zapisuje tylko raport + “todo remediation”.

2) Format danych “handoff” (co linter ocenia)

Minimalny obiekt wejściowy (może być wygenerowany przez Twój job, nie musi być 1:1 z tym schema — ważne, żebyś miał te pola w jakiejś formie):

{
  "runId": "NR-2026-02-11T22:30Z",
  "mode": "nightly_review|hotfix_only|manual",
  "timeWindow": { "from": "2026-02-11T00:00:00Z", "to": "2026-02-11T23:59:59Z" },

  "budgets": {
    "maxAgentsBulletsTotal": 60,
    "maxNewSlugsPerWeek": 2,
    "maxRulesPerSlug": 1
  },

  "slugsConfigVersion": 1,
  "allowedSlugs": ["tooling/file-ops", "safety/destructive-ops", "other/needs-triage"],

  "proposedOperations": [
    { "op": "replace_with_merged", "slug": "tooling/file-ops", "ruleIds": ["LRN-1","LRN-9"] }
  ],

  "proposedPromotions": [
    {

      "slug": "tooling/file-ops",
      "target": "AGENTS_RULES.md",
      "ruleText": "Prefer read/write/edit over shell cat/ls for workspace files. Exceptions: diagnostics only.",
      "evidence": {
        "verifiedCount": 2,
        "distinctContexts": 2,
        "userConfirmed": false,
        "messageIds": ["..."]
      },
      "expiresAt": null
    }
  ],

  "hotfixes": [
    { "id": "HF-7", "slug": "web/search", "expiresAt": "2026-02-17T00:00:00Z" }

  ],

  "changesSummary": {
    "filesTouched": ["AGENTS_RULES.md", ".learnings/LEARNINGS.md"],
    "notes": "..."
  }
}

3) Handoff Lint — zasady (PASS/WARN/FAIL)

Poniżej jest „lint rulebook”. Implementacyjnie możesz zrobić to jako:

czyste heurystyki, albo
heurystyki + LLM “judge” (JSON-only) tylko gdy potrzebujesz.

A. Anti‑bloat / kompresja

FAIL

AGENTS_RULES.md miałby mieć >1 regułę dla tego samego slug (łamie one rule per slug).
“append bez merge”: nowa reguła dla istniejącego sluga bez operacji typu replace_with_merged.
proponujesz promocję “mikro-reguły” (np. pojedyncza preferencja stylistyczna) jako global.

WARN

dodajesz nowy slug mimo że można wcisnąć do istniejącego (np. kolejny tooling/file-ops/* zamiast tooling/file-ops).
merge generuje regułę dłuższą niż ~280–400 znaków (zwykle znak, że to za dużo naraz).

B. Evidence gating (promocja tylko z dowodami)

FAIL

promocja do AGENTS/TOOLS/SOUL bez minimalnych dowodów:
- verifiedCount >= 2 albo userConfirmed=true
- i preferowane: distinctContexts >= 2 dla nie-trywialnych rzeczy

WARN

verifiedCount == 1 i brak potwierdzenia usera (ryzyko false positive).
brak messageIds / brak śladu skąd to przyszło (utrudnia debug).

C. TTL / hotfix hygiene

FAIL

hotfix jest promowany jako permanentny (TTL usunięte) bez dowodów verified.
w systemie zostają hotfixy po expiresAt < now (nie są wygaszane).

WARN

merge miesza verified rule + hotfix i robi wynik permanentny (zamiast propagować najbliższe expiresAt).

D. Scope (global vs local preference)

FAIL

reguła oznaczona jako “style/local_preference” trafia do AGENTS_CORE / globalnych zasad.

WARN

scope nie jest określony (albo nie da się go wywnioskować) dla rzeczy niebezpiecznych (safety/ops).

E. Safety / external actions

FAIL

jakakolwiek “operacja zewnętrzna” (wysyłka, publikacja, zmiany prod) bez flagi “userConfirmed”.
jakakolwiek destrukcja (delete/overwrite) bez guardów i planu rollback.

(W Twoim self‑improver to zwykle ma być po prostu: “nigdy nie rób external/destructive w nightly review”.)

F. Determinizm i idempotencja

FAIL

LLM‑etapy (merge/router/lint) nie zwracają strict JSON zgodnego ze schema.
brak “operations plan” (czyli nie wiadomo co dokładnie zmieniasz).

WARN

wynik zależny od kolejności wejść bez sortowania (np. reguły w klastrze nie są sortowane po id → niestabilne merge).

G. Budżety

FAIL

przekroczone twarde budżety (np. liczba bulletów w AGENTS, limit nowych slugów/tydzień) i brak konsolidacji.

WARN

budżety przekraczane trendem (np. +10% tygodniowo) — znak, że merge nie kompresuje wystarczająco.

4) Output lintera (JSON Schema) + przykładowy wynik

Schema: `handoff-lint-output.schema.json`

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "HandoffLintOutput",
  "type": "object",
  "additionalProperties": false,

  "required": ["status", "failures", "warnings", "recommendedActions", "confidence"],
  "properties": {
    "status": { "type": "string", "enum": ["pass", "warn", "fail"] },
    "failures": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["code", "message"],
        "properties": {
          "code": { "type": "string" },
          "message": { "type": "string" },
          "slug": { "type": "string" },
          "ruleIds": { "type": "array", "items": { "type": "string" } }
        }

      }
    },
    "warnings": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["code", "message"],
        "properties": {
          "code": { "type": "string" },
          "message": { "type": "string" },
          "slug": { "type": "string" }
        }
      }
    },

    "recommendedActions": {
      "type": "array",
      "items": { "type": "string" }
    },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 }
  }
}

Przykład outputu

{
  "status": "fail",
  "failures": [
    {

      "code": "ONE_RULE_PER_SLUG_VIOLATION",
      "message": "Proposed promotion would create 2 rules for slug tooling/file-ops in AGENTS_RULES.md. Must merge/replace.",
      "slug": "tooling/file-ops",
      "ruleIds": ["LRN-1", "LRN-9"]
    }
  ],
  "warnings": [
    {
      "code": "WEAK_EVIDENCE",
      "message": "Promotion has only 1 verified application and no user confirmation.",
      "slug": "web/search"
    }
  ],
  "recommendedActions": [
    "Run merge step again for slug tooling/file-ops and produce a single canonical rule.",

    "Do not promote web/search yet; keep as pending until verifiedCount>=2 or userConfirmed=true."
  ],
  "confidence": 0.84
}

5) Prompt do odpalenia Handoff Lint (LLM‑judge, JSON‑only)

Jeśli chcesz robić lint przez LLM (albo hybrydowo: heurystyki → LLM tylko do edge cases), to wklej:

You are a "Handoff Linter" for an autonomous agent's self-improvement pipeline.

Goal:
Given a handoff package describing proposed rule merges/promotions/hotfix TTLs, decide if it is safe and high-quality to apply.
Return ONLY valid JSON matching the provided HandoffLintOutput schema. No prose.

Hard checks (fail if violated):
- One rule per slug in AGENTS: do not allow duplicates; require merge/replace.
- Promotions require evidence: verifiedCount>=2 OR userConfirmed=true. Prefer distinctContexts>=2.
- Hotfix TTL: do not make hotfix permanent without evidence; expire hotfixes past expiresAt.
- Do not promote local/style preferences as global agent policy.
- No external/destructive actions unless explicitly userConfirmed (if any exist -> fail).

Soft checks (warnings):
- New slug creation when existing slug fits.
- Overly long merged rules.
- Missing source/evidence links (messageIds).

- Budget pressure trends.

Inputs:
handoff: {{HANDOFF_JSON}}
now: {{NOW_ISO}}
outputSchema: {{HANDOFF_LINT_OUTPUT_SCHEMA_JSON}}

Return JSON matching outputSchema.

Jeśli chcesz, podeślij mi proszę (w 1 poście) jak dokładnie teraz wygląda u Ciebie:

format Twoich “lesson entries” w .learnings/
jak zapisujesz hotfixy z TTL
jak wygląda AGENTS.md (czy już masz podział CORE/RULES)

…to dopasuję Ci ten Handoff Lint pod Twoje realne pola (kody błędów, budżety, minimalne evidence), żebyś mógł go wkleić 1:1 do skilla.

#dalsza pomoc w debugowaniu skilla

1) Co to jest “Handoff Lint” i gdzie go wpiąć

2) Format danych “handoff” (co linter ocenia)

3) Handoff Lint — zasady (PASS/WARN/FAIL)

A. Anti‑bloat / kompresja

B. Evidence gating (promocja tylko z dowodami)

C. TTL / hotfix hygiene

D. Scope (global vs local preference)

E. Safety / external actions

F. Determinizm i idempotencja

G. Budżety

4) Output lintera (JSON Schema) + przykładowy wynik

Schema: handoff-lint-output.schema.json

Przykład outputu

5) Prompt do odpalenia Handoff Lint (LLM‑judge, JSON‑only)

Schema: `handoff-lint-output.schema.json`