arthurpanhku/dvalincode

Why The roadmap puts fix-verification adoption at "activation rather than another UI projection" — shortening install-to-proof time. The cheapest activation path may not be another Dvalin surface at all. The field is standardising on in-toto / SLSA provenance attestations verified with Sigstore/cosign before promotion: pipelines already check signature and integrity of generation metadata as a gate. A VFR emitted as (or alongside) an in-toto attestation would drop into those pipelines without anyone adopting Dvalin tooling first — the verification happens in machinery they already run. Worth noting the thesis is being restated independently. From a third-party writeup on AI-generated code: provenance "should be captured in the layer that runs the agent before the commit exists, then bound to the diff, scan output, recorded session, and governing policy." That is FVP-1's argument in someone else's words. Validation — and a signal that the window for being the reference implementat

Why The Evidence Pack maps to OpenSSF and ISO-42001 today. Two control sets published since are a closer fit for what Dvalin actually governs, and both are third-party — which is worth more against the roadmap's north star ("trivially approvable by any company's security review") than another profile we wrote ourselves. NSA — Model Context Protocol: Security Design Considerations (June 2026) A dated, government-issued control set for exactly the surface docs/GOVERNED-MCP.md covers. Its threat model — prompt injection, tool poisoning, confused-deputy OAuth abuse, token passthrough, supply-chain compromise — lines up with our chokepoints closely enough that a mapping table would mostly be citation, not new work. For contractors and critical-infrastructure operators, "maps to the NSA CSI" is a sentence that ends a procurement argument. OWASP Top 10 for Agentic Applications 2026 Its guidance to "maintain tamper-evident logs with cryptographic binding to agent identity for non-repud

What docs/COMPETITIVE-ANALYSIS.md cites 「EU AI Act 高风险义务 2026-08-02 生效」 as regulatory tailwind in three places — lines 88, 136 and 270. That date no longer holds. Regulation (EU) 2026/1744 (the Digital Omnibus on AI) was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It defers: Annex III standalone high-risk systems: 2 August 2026 → 2 December 2027 Annex I high-risk in regulated products: → 2 August 2028 The Commission's stated reason was that neither industry nor CEN/CENELEC would have harmonised standards ready, and the conformity-assessment infrastructure the Act assumes had not matured. Why it's worth fixing rather than leaving The document argues Dvalin's hash-chain audit and Evidence Pack catch a regulatory wave. That argument survives — but a security reviewer who follows this file will notice the date passed with nothing happening, which undercuts the surrounding claims more than the correction costs. The ta

What Dvalin's MCP client and server disagree about which protocol version we speak. src/mcp/client.ts:11 — export const PROTOCOL_VERSION = '2025-06-18', sent by client.ts and stdio.ts on every initialize. src/mcp/server.ts:49 — SUPPORTED_PROTOCOL_VERSIONS = ['2025-11-25', '2025-06-18', '2025-03-26', '2024-11-05']. Nothing is broken: negotiation handles the mismatch and the installed SDK knows up to 2025-11-25 either way. But Dvalin-as-client never negotiates above 2025-06-18 against any external server, so anything added in 2025-11-25 is unreachable from our side of the connection. That looks unintentional rather than chosen — if it is chosen, the constant deserves a comment saying why, since the next person to read it will assume it is drift. While in there: src/mcp/client.ts:12 has CLIENT_INFO = { name: 'dvalincode', version: '0.9.0' }, which is what we announce to every server we connect to. The package is at 0.19.0, so we have been introducing ourselves under a version we s

What is wrong evaluateVerificationGate fails a run whose worktree has no code changes (src/remediation/automate.ts:89), but that condition is not represented in the record's verdict. evaluateFixVerdictV2 (src/security/fixRecord.ts:214) takes checks, remainingTargets, introduced, gate, and the two coverages — nothing about whether anything was edited. So a run where the targets vanished from the re-scan, the project's checks passed, and the repair changed no files issues a record saying verified: true, then throws: src/commands/dvalin.ts:307 hasChanges: Boolean(status.trim()) src/remediation/automate.ts:89 'the remediation worktree has no code changes' This is the same shape as the two-definitions defect closed by #217 / #218 — the command's gate and the record's verdict disagreeing — and it is what remains of it. It is far rarer: it needs the re-scan to stop reporting a finding that no edit removed, which means a flaky or non-deterministic scanner, a scanner that dropped out