norvidize
Extract and audit claims for norvid tracking system
- License 许可
- Apache-2.0
- 最近更新
- 2026-07-12
- Stars
- ★ 82
- Forks
- 18
01 前言 Front Matter
- name
- norvidize
- description
- Extract and audit claims for norvid tracking system
03 SKILL.md 正文
Norvidize Skill
<<<<<<< HEAD Extract claims from documentation, code, and tests into a claim tracking system based on multicomputational irreducibility -- claims that cannot be reduced to simpler forms without losing verification guarantees.
Extract claims from documentation, code, and tests into the norvid claim tracking system.
origin/main
When to Use
- After completing a significant feature
- When auditing documentation accuracy
- Before releases to ensure claims match reality
- When docs/tests/specs diverge from implementation
<<<<<<< HEAD
Claim Registry Location
crates/basin-norvid/src/claims.rs
origin/main
Assurance Levels (lowest to highest)
| Level | Meaning | Evidence Required |
|---|---|---|
| Mentioned | Just referenced somewhere | Any doc |
| <<<<<<< HEAD | ||
| Designed | Has design doc | Design markdown |
| Specified | Has formal spec | Spec file |
| Implemented | Code exists | Source file + symbol |
| Tested | Has passing tests | Test file + test name |
| Proven | Has formal proof | Proof file + theorem |
| ======= | ||
| Designed | Has design doc | docs/design/*.md |
| Specified | Has sigil spec | *.sigil file |
| Implemented | Code exists | Rust file + symbol |
| Tested | Has passing tests | Test file + test name |
| Proven | Has Lean proof | Lean file + theorem |
origin/main
Claim Categories
- Feature: User-visible functionality
- Property: System guarantee (linearizability, durability)
- Guarantee: Promise to users
- Optimization: Performance improvement
- Invariant: Internal system invariant
- Decision: Architectural choice with rationale
- Omission: Deliberate non-feature
<<<<<<< HEAD
Covariant Claim Structure
Claims form a presheaf over the assurance poset: higher assurance levels pull back evidence from lower levels. A Tested claim covariantly transports its Designed evidence forward.
Mentioned -> Designed -> Specified -> Implemented -> Tested -> Proven
Each arrow preserves evidence (covariant functor from assurance levels to evidence sets).
Evidence Types
// Documentation
Evidence::doc("docs/CLAIMS.md")
// Rust implementation
Evidence::rust("crates/foo/src/bar.rs", "SymbolName")
// Test file
Evidence::test("crates/foo/src/bar.rs", "test_prefix")
// Sigil specification
Evidence::sigil("sigil/specs/foo.sigil")
// External (benchmark, paper)
Evidence::external("benchmarks/harnesses/redis/src/main.rs")
Adding Claims
registry.register(
Claim::new("CLM_UNIQUE_ID", "Short description")
.with_category(Category::Feature)
.with_component(Component::Slate)
.with_assurance(Assurance::Implemented)
.with_evidence(Assurance::Designed, Evidence::doc("docs/design/foo.md"))
.with_evidence(Assurance::Implemented, Evidence::rust("crates/slate/src/lib.rs", "FooStruct"))
);
origin/main
Extraction Process
1. Find Candidate Claims
<<<<<<< HEAD Scan sources for claim candidates:
grep -r "CLAIM\|GUARANTEE\|INVARIANT" docs/
grep -r "#\[test\]" -A 2 src/ | grep "fn test_"
grep -r "ops/s\|latency\|throughput" docs/
2. Categorize by Irreducibility
- Irreducible claims: Cannot be verified by simpler means (need full test execution)
- Reducible claims: Can be statically verified (type checking, linting)
- Compositional claims: Verified by composing sub-claim verifications
3. Verify Evidence Paths
Before adding at Tested/Implemented level, verify paths exist.
4. Downgrade Strategy
If evidence path is uncertain, downgrade assurance level. Upgrade later when evidence is confirmed.
Anti-Patterns
- Don't add Tested claims without verifying paths
- Don't skip Designed level -- even Tested claims should have design evidence
- Don't guess component names ======= Scan these sources for claim candidates:
# Explicit claims in docs
grep -r "CLM-\|CLAIM\|GUARANTEE\|INVARIANT" docs/
# Test names suggest guarantees
grep -r "#\[test\]" -A 2 crates/ | grep "fn test_"
# Performance claims
grep -r "ops/s\|latency\|throughput" docs/
# Sigil specs
find sigil/ -name "*.sigil" -exec grep -l "claim\|invariant\|property" {} \;
2. Categorize and Deduplicate
Group into tiers:
- Tier 1 (SPEC_*): Claims with sigil specs - highest value
- Tier 2 (TEST_*): Claims with test evidence
- Tier 3: Design-level claims (docs only)
3. Verify Evidence Paths
Before adding at Tested/Implemented level, verify paths exist:
# Check file exists
test -f "crates/basin-redis/src/crdt.rs" && echo "OK"
# Check symbol exists
grep -l "EntityStore" crates/basin-meta/src/indexes/*.rs
4. Add to Registry
Add claims to claims.rs in appropriate section:
- SPEC_* claims near line 1720
- TEST_* claims after specs
- PERF_* claims in performance section
- Product claims (CLM_STASH, etc.) with products
CI Verification
The CI test filters claims at Tested/Proven level and verifies:
- Evidence file exists
- Symbol/test found in file
# Run verification
graft test -p basin-norvid test_all_claims_verified
Common Path Mappings
| Old/Wrong Path | Correct Path |
|---|---|
crates/stash/ |
crates/basin-redis/ |
crates/shelf/ |
crates/basin-mesh/ or crates/spool-core/ |
crates/basin-jepsen/ |
tests/basin-jepsen/ |
products/nfs/tests/ |
crates/nfs/tests/ |
Downgrade Strategy
If evidence path is uncertain, downgrade to Designed level:
// Was Tested but can't verify path
.with_assurance(Assurance::Designed)
.with_evidence(Assurance::Designed, Evidence::doc("docs/CLAIMS.md"))
Upgrade later when evidence is confirmed.
Parallel Audit Pattern
For bulk verification, spawn sonnet agents:
Task: Audit PERF_* claims
- Check benchmark files exist
- Verify they actually measure what claim says
- Report which claims have valid evidence
Task: Audit product claims (CLM_STASH, etc.)
- Find actual test locations
- Verify symbol names
- Report path corrections needed
Anti-Patterns
- Don't add Tested claims without verifying paths - CI will fail
- Don't embed large values in claim IDs - Keep IDs short like
CLM_STASH - Don't skip Designed level - Even Tested claims should have design evidence
- Don't guess component names - Check
Componentenum in identity.rs
Quick Reference
# Find existing claims
grep -n "Claim::new" crates/basin-norvid/src/claims.rs | head -20
# Check CI status
graft test -p basin-norvid test_all_claims_verified 2>&1 | grep -E "FAILED|passed"
# Find test files for a crate
find crates/basin-meta -name "*.rs" -exec grep -l "#\[test\]" {} \;
# Count claims by category
grep -E "Category::" crates/basin-norvid/src/claims.rs | sort | uniq -c
origin/main
04 同仓库更多 Skills
로인장 (Roinjiang)
Activates when the user needs legal advice, contract review, insurance law consultation, startup legal support, or any legal/regulatory matter. She is a top-tier in-house lawyer with absolute loyalty to the CEO, specializing in insurance law, financial consumer protection, privacy, contracts, labor law, family law, civil and criminal matters.
zocdoc-doctor-finder
Use when a user needs to find a doctor, dentist, specialist, therapist, or healthcare provider — especially when they mention insurance, in-network, availability, location, appointments, or booking. Also use for browsing provider reviews, comparing doctors by specialty, or checking if a provider takes their insurance.
zenmux-context
Answers any question about ZenMux by reading the latest official documentation. Use this skill whenever the user asks about ZenMux product features, API usage, configuration, integration, pricing, models, providers, routing, fallback, streaming, multimodal, structured output, tool calling, reasoning, prompt caching, image generation, video generation, web search, long context, observability, logs, cost tracking, usage analytics, insurance, subscription, pay-as-you-go, invoices, best practices for tools like Claude Code, Cursor, Cline, CodeX, Gemini CLI, opencode, Cherry Studio, Obsidian, Sider, Open-WebUI, Dify, Neovate, GitHub Copilot, OpenClaw, CC-Switch, Immersive Translate, Studio Chat, architecture, benchmarks, FAQ, contact, privacy, terms of service, compliance, or any other ZenMux-related topic. Also trigger when the user writes in Chinese about ZenMux: 文档, 使用指南, 快速开始, API 参考, 最佳实践, 模型路由, 供应商路由, 订阅, 按量计费, 可观测性, 帮助, 常见问题, 接入指南, 配置. Trigger on phrases like "how to use ZenMux", "ZenMux docs", "ZenMux API", "ZenMux integration", "ZenMux 怎么用", "ZenMux 接入", "ZenMux 配置". Even if the user doesn't say "ZenMux" explicitly but asks about LLM API aggregation, model routing, provider fallback in a context where ZenMux is the project being worked on, this skill should activate.
workers-comp-guide
Guide workers compensation compliance and claims management. TRIGGERS - Use when user needs help with workers-comp-guide related tasks.
weekly-kpi-report
Generate McKinsey-style board presentation PPTs from weekly auto insurance data. Automatically calculates 16+ KPIs, creates executive-level slides with actionable insights, and supports week-over-week comparisons. Use when user uploads insurance cost data (Excel/CSV) and requests board report, weekly presentation, executive briefing, or mentions keywords like 董事会汇报, 周报PPT, 经营分析演示, McKinsey-style reports.
wealth-advisory
Wealth management and financial planning for HNW and UHNW clients. Activate when the user mentions wealth management, financial planning, retirement, estate planning, tax planning, GRAT, IDGT, trust, asset allocation, withdrawal rate, Monte Carlo simulation, goals-based investing, tax-loss harvesting, Roth conversion, insurance, annuity, mortgage strategy, concentrated stock, family office, direct indexing, 529 plan, charitable giving, donor-advised fund, private foundation, or asks about personal finance strategy, inheritance, long-term financial planning, or UHNW advisory.