pi-ui-extend 1.0.42 → 1.0.45

package/skills/spec-wiki/evals/trigger-evals.json

@@ -1,94 +0,0 @@
-[
-  {
-    "query": "Before we touch src/auth/session.ts, write a compact spec for the new refresh-token rotation behavior. It changes persistence and the public login flow, and I want the expected behavior and verification path clear before implementation.",
-    "should_trigger": true
-  },
-  {
-    "query": "We have a pile of design docs under docs/, architecture/, and feature folders with no central specs directory. Find which ones are actual behavioral specs and build a small LLM-friendly project spec index without treating existing overview pages as source-of-truth.",
-    "should_trigger": true
-  },
-  {
-    "query": "src/jobs/runner.ts changed yesterday. Can you tell me which project specs may now be stale and check whether the documented cancellation/retry behavior still matches code and tests?",
-    "should_trigger": true
-  },
-  {
-    "query": "Which of our specs defines desktop session restore behavior? Please answer from the primary spec rather than scanning every markdown file, and warn me if the relevant spec looks stale.",
-    "should_trigger": true
-  },
-  {
-    "query": "The bug fix changes an externally visible CLI exit-code contract. Update the existing spec to describe the intended behavior, edge cases and compatibility, but don't implement the code yet.",
-    "should_trigger": true
-  },
-  {
-    "query": "Document the current as-is behavior of our webhook retry loop from code and tests. I'm especially worried the README is stale, so separate confirmed behavior from inference and unknowns.",
-    "should_trigger": true
-  },
-  {
-    "query": "We renamed several contract docs and moved implementation files. Refresh the project's spec knowledge base, repair missing paths, and show me which specs still need semantic review.",
-    "should_trigger": true
-  },
-  {
-    "query": "What do the project requirements say about idempotency for payment capture? There are multiple RFCs and an overview; find the primary spec and answer with its source path.",
-    "should_trigger": true
-  },
-  {
-    "query": "I'm about to change the on-disk cache schema. Check if we already have a spec for that behavior; if not, create a lightweight change spec before touching implementation.",
-    "should_trigger": true
-  },
-  {
-    "query": "Inventory the behavioral contracts in this unfamiliar repo and tell me which ones are affected by the changes in src/api and src/storage. Specs may be scattered and inconsistently named.",
-    "should_trigger": true
-  },
-  {
-    "query": "Implement background session refresh so a transient token-load failure is retried exactly once and a second failure still propagates. Add the code and tests and verify the change is complete.",
-    "should_trigger": true
-  },
-  {
-    "query": "I added a new src/auth/refresh-policy.ts implementation surface for an existing login behavior. Finish the change and make sure any project contracts or knowledge that should track the new file stay current.",
-    "should_trigger": true
-  },
-  {
-    "query": "Refactor src/utils/string.ts to use a helper function. This is a mechanical cleanup with no externally visible behavior change; just update the code and tests.",
-    "should_trigger": false
-  },
-  {
-    "query": "Write an ADR comparing Postgres and SQLite for a future analytics service. I want design tradeoffs and a decision record, not a behavior contract or spec audit.",
-    "should_trigger": false
-  },
-  {
-    "query": "Rewrite docs/getting-started.md so new users understand how to log in and run the CLI. Keep it friendly and add examples.",
-    "should_trigger": false
-  },
-  {
-    "query": "Search all markdown files for the exact string `refresh_token` and show me the matching lines. Don't interpret or update any documentation.",
-    "should_trigger": false
-  },
-  {
-    "query": "Trace callers of createSession and tell me what code modules would be affected by changing its return type. I only need code impact analysis, not documentation work.",
-    "should_trigger": false
-  },
-  {
-    "query": "Generate API reference pages from our OpenAPI JSON and publish them under docs/generated/. The schema is already authoritative; don't create or review project specs.",
-    "should_trigger": false
-  },
-  {
-    "query": "Summarize architecture/rfc-019.md for me in five bullets. I only want a summary of this one file, not a spec validation or project knowledge index.",
-    "should_trigger": false
-  },
-  {
-    "query": "Fix the typo in the error message in src/ui/toast.ts and adjust the snapshot. No contract or compatibility behavior changes.",
-    "should_trigger": false
-  },
-  {
-    "query": "Create a migration runbook for operators moving production from Redis 6 to Redis 7, including rollback commands and monitoring checks.",
-    "should_trigger": false
-  },
-  {
-    "query": "Compare these two external W3C specifications and explain the differences in browser behavior. This isn't about specs stored in our project.",
-    "should_trigger": false
-  },
-  {
-    "query": "Add a debug-only telemetry label to an internal helper and update its unit test. It must not change any user-visible behavior, persistence, API, retry, or compatibility contract.",
-    "should_trigger": false
-  }
-]

package/skills/spec-wiki/references/bootstrap.md

@@ -1,100 +0,0 @@
-# Bootstrap the Spec Wiki
-
-Use for repository-wide discovery when no useful `.spec-wiki/state.json` exists,
-or when the user explicitly asks to inventory scattered specifications.
-
-The repository may have no `specs/` directory, no frontmatter, inconsistent
-formats, and multiple documentation roots.
-
-## Workflow
-
-1. Run `discover --limit 40`.
-2. Read only the high-signal shortlist.
-3. Semantically classify each candidate:
-   - `spec` — primary normative/descriptive specification;
-   - `spec-like` — useful spec knowledge with mixed/ambiguous purpose;
-   - `meta-index` — overview, inventory, catalog, TOC, generated index;
-   - `design-only` — design/decision material without enough behavioral contract;
-   - `guide` — tutorial/runbook/usage documentation;
-   - `other` — not useful spec knowledge.
-   Treat files under eval/fixture/example/testdata trees, skill resources, and
-   agent-role definition directories as examples/runtime configuration by
-   default, not project primary specs, unless repository evidence explicitly
-   says that document itself is normative project behavior.
-
-   Location is not a reason to downgrade a document. A document outside a
-   `specs/` directory that explicitly declares its behavioral Type/Lifecycle
-   and defines testable behavior/contracts/invariants should normally be
-   `spec`. Reserve `spec-like` for genuinely mixed-purpose or ambiguous
-   documents, not for clear subsystem contracts living under `docs/`.
-4. `record` every reviewed classification. For `spec`/`spec-like`, provide a
-   concise summary, type, lifecycle, confidence, and a few retrieval topics.
-   Classification/indexing is **not** semantic verification: bootstrap entries
-   normally remain `unverified` until a focused code/test review occurs.
-5. After recording a batch, rerun `discover --limit 40` from offset 0; unchanged
-   reviewed documents drop from the default shortlist.
-6. Continue until useful candidates are exhausted or coverage becomes too broad.
-   Report incomplete coverage rather than reading hundreds of weak candidates.
-7. Run `render` and `validate`.
-
-Do not call `verify` merely because a document was read during discovery. Call
-it only after checking the document's behavioral claims against the relevant
-implementation/tests (or other authoritative evidence for a proposed contract).
-
-## What counts as a primary spec
-
-A primary spec describes current or intended behavior, requirements, contracts,
-invariants, externally observable semantics, acceptance criteria, compatibility
-rules, or similarly testable expectations.
-
-Classification is semantic. Filename, folder, headings, and links are signals,
-not requirements.
-
-## Lifecycle
-
-Classify primary documents separately from their as-is/change type:
-
-- `active` — current authoritative contract;
-- `proposed` — intended contract not yet established as current behavior;
-- `historical` — useful milestone/history, not current precedence;
-- `superseded` — replaced by a newer primary spec; add `--superseded-by`;
-- `unknown` — lifecycle cannot be established safely.
-
-Useful default reasoning:
-
-- an as-is/current-behavior contract is normally `active` unless clearly
-  historical;
-- a change document whose behavior is already implemented and still governs the
-  system is normally `active`;
-- an intended/not-yet-implemented change is `proposed`;
-- milestone documents whose former non-goals/features were later superseded are
-  `historical` unless a newer document explicitly replaces their whole contract;
-- use `superseded` only when a specific replacement exists and record that edge.
-
-The CLI requires explicit `--type` and `--lifecycle` on the first primary-spec
-record so omission cannot silently become precedence metadata.
-
-Use `--supersedes` / `--superseded-by` for known precedence instead of leaving
-overlapping documents as coequal active specs.
-
-## Meta/index exclusion
-
-Do not index derived inventories as primary specs. They are useful only to find
-primary documents missed by heuristics. This avoids recursive knowledge such as:
-
-`spec -> old index summary -> new wiki summary`.
-
-## Relationships
-
-The CLI extracts resolvable source links/paths as `explicit` relationships. Add
-`--code` or `--related-spec` only for relationships actually established from
-repository evidence; these are recorded as `inferred`.
-
-The resolver tries the source directory, nearest package/project roots, and the
-repository root. Review `unresolvedReferences` after bootstrap: they are path-like
-hints that could not be resolved deterministically and may need an inferred
-relation or a source-doc fix.
-
-Use project-relative path identity, never numeric prefixes as unique IDs.
-
-For exact command/config/state details, read `index-schema.md`.

package/skills/spec-wiki/references/focused-spec.md

@@ -1,117 +0,0 @@
-# Focused spec work
-
-Use this workflow for creating, updating, or checking one primary spec. Keep the
-scope narrow; repository-wide indexing is optional unless it helps retrieval.
-
-## Core rules
-
-- Do not change production code unless implementation was requested.
-- Do not invent behavior. Mark ambiguity as inferred or unknown.
-- Prefer compact specs over exhaustive design documents.
-- Read only relevant code, tests, schemas, migrations, entrypoints, docs, and
-  existing specs.
-- Follow the project's existing documentation convention when one exists.
-- Describe current behavior as `as-is`; intended behavior as `change`.
-
-## When a spec is useful
-
-Prefer a focused spec for changes involving security/auth/privacy, data or
-persistence, public APIs/CLI/UI/events, integrations, destructive operations,
-async/concurrency/retries, cross-cutting architecture, non-trivial user-visible
-edge cases, unclear bug-fix contracts, or suspected spec-code drift.
-
-Do not force a spec for formatting-only edits, mechanical renames, or obvious
-local changes without broader behavioral impact.
-
-## As-is / drift workflow
-
-1. Identify the narrow behavior or contract.
-2. If a Spec Wiki already exists, use it only to locate related primary specs.
-3. Inspect the relevant code, tests, docs, schemas, migrations, and entrypoints.
-4. Separate claims as:
-   - confirmed by code;
-   - confirmed by tests;
-   - confirmed by docs;
-   - inferred;
-   - unknown.
-5. Write/update a compact as-is spec.
-6. Report detected drift separately from confirmed behavior.
-7. If the project uses Spec Wiki, `record` the spec/relations, then run `verify`
-   only after the code/test semantic check is complete, and `render`.
-
-## Change workflow
-
-1. Define goal, scope, and non-goals.
-2. State intended behavior.
-3. Capture affected contracts and invariants.
-4. Add relevant edge cases, compatibility, migration, and risks.
-5. Define verification.
-6. Implement only when requested.
-7. After implementation, verify the spec against code/tests.
-8. For a material production-behavior change, run the post-change checkpoint in
-   `maintenance.md` using the paths changed by this task. This is required even
-   when the spec you started from appears sufficient: newly introduced files may
-   reveal previously unknown spec relationships.
-9. If the project uses Spec Wiki, refresh metadata with `record`, repair durable
-   relation changes with `relate`, then establish the verified baseline with
-   `verify` only after implementation/test verification and the impact sweep.
-
-If the task creates a new primary spec, record it immediately. If it moves a
-primary spec, record/verify the new path before removing the old metadata entry.
-
-## Default template
-
-Use only when the repository has no stronger convention. Remove irrelevant
-sections.
-
-```markdown
-# Spec: <name>
-
-## Type
-As-is | Change
-
-## Goal
-...
-
-## Scope
-...
-
-## Non-goals
-...
-
-## Behavior
-...
-
-## Contracts
-Inputs, outputs, APIs, CLI, UI, events, files, schemas.
-
-## Invariants
-...
-
-## Edge cases
-...
-
-## Side effects
-...
-
-## Related files
-...
-
-## Verification
-...
-
-## Risks / unknowns
-...
-
-## Evidence
-- Confirmed by code:
-- Confirmed by tests:
-- Confirmed by docs:
-- Inferred:
-- Unknown:
-```
-
-## Report back
-
-Summarize the spec path, as-is/change mode, strongest evidence, important
-unknowns/drift, and whether production code was changed.

package/skills/spec-wiki/references/index-schema.md

@@ -1,330 +0,0 @@
-# Spec Wiki state and CLI reference
-
-<!-- markdownlint-disable MD013 -->
-
-This reference describes the deterministic storage layer. Primary specification
-documents remain the source of truth.
-
-## Files
-
-```text
-.spec-wiki/index.md      # compact generated routing index
-.spec-wiki/state.json    # semantic metadata + structural/verification baselines
-.spec-wiki/config.jsonc  # optional discovery overrides
-```
-
-## State schema v2
-
-Conceptual primary entry:
-
-```json
-{
-  "path": "docs/auth.md",
-  "title": "Authentication contract",
-  "classification": "spec",
-  "type": "as-is",
-  "lifecycle": "active",
-  "confidence": "high",
-  "summary": "Authentication session lifecycle and refresh invariants.",
-  "topics": ["auth", "sessions"],
-  "relations": {
-    "code": [
-      {"path": "src/auth/session.ts", "source": "explicit"}
-    ],
-    "specs": [
-      {"path": "docs/oauth.md", "source": "inferred", "kind": "related"}
-    ]
-  },
-  "unresolvedReferences": [],
-  "indexed": {
-    "at": "2026-09-09T00:00:00Z",
-    "sourceHash": "sha256:..."
-  },
-  "verified": {
-    "at": "2026-09-09T00:05:00Z",
-    "sourceHash": "sha256:...",
-    "relationsHash": "sha256:...",
-    "codeHashes": {
-      "src/auth/session.ts": "sha256:..."
-    }
-  }
-}
-```
-
-State keys and all stored paths are normalized project-relative POSIX paths.
-
-### Classification
-
-- `spec` — primary behavioral/normative specification.
-- `spec-like` — primary-ish knowledge with mixed/ambiguous purpose.
-- `meta-index` — inventory, overview, catalog, TOC, generated index.
-- `design-only` — design/decision material without enough behavioral contract.
-- `guide` — tutorial, runbook, usage/operational documentation.
-- `other` — not useful specification knowledge.
-
-Only `spec`/`spec-like` are primary specs. `design-only` may be searched as
-secondary context with `search --include-secondary`.
-
-### Type
-
-- `as-is` — describes current behavior.
-- `change` — intended/changed behavior.
-- `mixed` — intentionally contains both.
-- `unknown` — not safely determined.
-
-### Lifecycle
-
-Lifecycle is separate from Type:
-
-- `active` — current authoritative contract.
-- `proposed` — intended contract that is not yet current.
-- `historical` — useful milestone/history, not current precedence.
-- `superseded` — replaced by a newer primary document.
-- `unknown` — precedence cannot be established safely.
-
-For known replacement relationships use:
-
-- `kind: related`
-- `kind: supersedes`
-- `kind: superseded-by`
-
-### Indexed vs verified
-
-`indexed` is refreshed by `record`. It means the document was classified and
-summarized at that exact source hash.
-
-`verified` is written only by `verify`. It means the agent has semantically
-checked the spec against its relevant implementation/tests/evidence and accepted
-the current tracked-input baseline. The baseline also fingerprints the current
-code/spec relation map. Adding or removing a relation therefore invalidates
-freshness until semantic review and `verify` establish a new baseline.
-
-Therefore a clean bootstrap produces `unverified` primary specs, not `fresh`.
-
-## Freshness statuses
-
-- `fresh` — source and tracked code inputs match an explicit verified baseline.
-- `unverified` — indexed but no semantic-verification baseline exists.
-- `spec-changed` — source differs from indexed/verified baseline.
-- `inputs-changed` — one or more tracked implementation inputs differ/missing.
-- `spec+inputs-changed` — both source and implementation inputs changed.
-- `missing-source` — primary source disappeared/moved.
-
-Hash status is structural evidence only; `inputs-changed` requests semantic
-review and must not rewrite behavior automatically.
-
-## Relationship discovery
-
-Explicit path/link resolution tries, in order:
-
-1. the source document directory;
-2. ancestor package roots containing markers such as `package.json`,
-   `pyproject.toml`, `Cargo.toml`, `go.mod`, or `Package.swift`;
-3. repository root.
-
-This lets a doc under `external/package/docs/` resolve `src/foo.ts` against the
-package root. Simple `{a,b}` path groups are expanded.
-
-If the document explicitly says that paths/references below are relative to a
-backticked existing project directory (for example `external/tool-suite/`), that
-directory is also used as a resolution base. This covers root-level specs that
-document one nested package using package-relative paths.
-
-Path-like tokens that still cannot resolve are stored in
-`unresolvedReferences`. They are diagnostic hints, not silently discarded.
-
-## Optional config.jsonc
-
-```jsonc
-{
-  "includeExtensions": [".md", ".mdx", ".rst", ".adoc", ".txt"],
-  "include": ["docs/**", "architecture/**", "features/**"],
-  "exclude": ["legacy/**", "generated-docs/**"],
-  "forceSpecs": ["protocol/*.txt"],
-  "ignoreSpecs": ["docs/spec-template.md"],
-  "minCandidateScore": 3,
-  "maxFileBytes": 524288
-}
-```
-
-The scanner excludes its own state plus common dependency/build/cache dirs.
-When Git is available it uses tracked + unignored untracked files; hashing also
-works without Git.
-
-## CLI
-
-Global options:
-
-```text
---root PATH       project root; defaults to Git root, then cwd
---state-dir PATH  alternate wiki directory; relative paths are root-relative
---config PATH     alternate config.jsonc/json path
-```
-
-### discover
-
-```bash
-spec_wiki.py --root . discover --limit 40
-spec_wiki.py --root . discover --all --json
-spec_wiki.py --root . discover --all-unclassified --limit 40
-```
-
-Produces a heuristic shortlist. `roleHint` is not a semantic classification.
-After recording a page, rerun from offset 0 because the shortlist shrinks.
-`--all-unclassified` is a bounded periodic coverage audit: it bypasses candidate
-score for unclassified document-like files while still excluding known
-fixture/skill-resource noise unless forced by config.
-
-### record
-
-```bash
-spec_wiki.py --root . record \
-  --path docs/auth.md \
-  --classification spec \
-  --type as-is \
-  --lifecycle active \
-  --confidence high \
-  --summary "Authentication lifecycle and refresh invariants." \
-  --topic auth --topic sessions \
-  --code src/auth/session.ts \
-  --related-spec docs/oauth.md
-```
-
-`record` updates classification, summary, topics, relationships, unresolved
-references, and the `indexed` source hash. It **does not verify** the entry.
-The first `spec`/`spec-like` record requires explicit `--type` and
-`--lifecycle` (use `unknown` only after semantic inspection cannot decide).
-
-Additional spec relationship flags are repeatable:
-
-```text
---supersedes PATH
---superseded-by PATH
-```
-
-`--clear-code` and `--clear-related-specs` remove previously inferred relations;
-explicit source links are re-extracted each time.
-
-### verify
-
-```bash
-spec_wiki.py --root . verify --path docs/auth.md
-```
-
-Run only after semantic review. It hashes the current source and every tracked
-code/test input plus the current relation map and establishes the new verified
-baseline. Missing tracked inputs fail rather than being silently accepted.
-
-### relate
-
-Use `relate` to repair inferred relations without resupplying the full semantic
-record:
-
-```bash
-spec_wiki.py --root . relate --path docs/auth.md --add-code src/auth/refresh.ts
-spec_wiki.py --root . relate --path docs/auth.md --remove-code src/auth/legacy.ts
-```
-
-It also supports add/remove variants for related specs, `supersedes`, and
-`superseded-by`. Explicit relations extracted from the primary source are not
-removed by this command; correct the source document instead. A real relation
-change makes the previous verified baseline non-fresh through `relationsHash`.
-
-### search
-
-```bash
-spec_wiki.py --root . search "session cancellation retry" --limit 8
-spec_wiki.py --root . search "как восстановить историю" \
-  --also "session recovery raw history after compaction" \
-  --also "session recovery tools" --json
-spec_wiki.py --root . search "context gateway" --include-secondary --json
-```
-
-Searches state metadata directly: title, topics, summary, spec path, known code
-relations, related-spec relations, and supersession edges. Exact spec/relation
-paths have strong weight. Relation token scoring uses concrete leaf names rather
-than generic directory segments.
-
-`--also` is repeatable. The CLI scores each formulation independently, then
-merges them deterministically. The intended caller is the current LLM: preserve
-the original request and, for natural-language intents, add 2–3 genuinely
-different English formulations (canonical contract nouns/synonyms plus implied
-failure/invariant vocabulary) without making another model call. Exact paths and
-symbols usually need no expansion.
-
-JSON output includes `confidence`, `catalogFallbackRecommended`,
-`semanticRerankRecommended`, coverage metrics, and per-query match evidence.
-These are routing hints, not semantic proof. The agent still reranks candidates
-from compact metadata. If fallback is recommended, results are empty, or the
-candidate set plainly misses part of the intent, inspect the compact generated
-`index.md` before deciding no relevant spec exists.
-
-Active specs rank above proposed/historical/superseded ones. This is the normal
-retrieval path; reading the entire generated index is a semantic fallback.
-
-### status / audit
-
-```bash
-spec_wiki.py --root . status
-spec_wiki.py --root . audit --json
-```
-
-Reports current/proposed primary count, fresh/unverified/review counts,
-unresolved reference count, missing sources, and new/changed candidates.
-`needs review` counts structural drift/missing sources; cleanly indexed but never
-verified specs are reported separately as `unverified`.
-
-### affected
-
-```bash
-spec_wiki.py --root . affected src/auth/session.ts src/storage
-```
-
-Returns current/proposed primary specs whose source or tracked code relations
-overlap supplied paths. Historical/superseded specs are skipped.
-
-### changes / impact
-
-```bash
-spec_wiki.py --root . changes --json
-spec_wiki.py --root . impact src/auth/session.ts src/auth/refresh.ts --json
-spec_wiki.py --root . impact --base HEAD --json
-```
-
-`changes` reports Git worktree changes, untracked files, and renames while
-excluding Spec Wiki's own state directory.
-
-`impact` is the deterministic post-change maintenance primitive. Explicit paths
-keep it scoped to the current task; with no paths it uses Git changes against
-`--base`. It returns known affected specs, uncovered changed paths, every changed
-document-like file (even score-0), missing/moved tracked specs, and a
-`semanticSweepRequired` flag. Uncovered paths are search seeds for LLM semantic
-impact review, not proof that a spec is missing.
-
-### render
-
-```bash
-spec_wiki.py --root . render
-```
-
-Generates a compact one-line-per-spec routing index. Historical/superseded specs
-and secondary design references are separate sections. Full summaries remain in
-state and are retrieved through `search`.
-
-### remove
-
-```bash
-spec_wiki.py --root . remove --path docs/old-contract.md
-```
-
-Removes metadata only. For a move, record the new path before removing the old.
-
-### validate
-
-```bash
-spec_wiki.py --root . validate
-```
-
-Checks schema/path/hash/relationship safety. Stale/unverified current specs,
-unresolved path hints, and active as-is specs without implementation relations
-are warnings rather than malformed-state errors.