[v3.18 spec-cmd] spec-cmd hardening: drift detection, CI gate, self-authoring

[Delqhi]

Spec-Layer Hardening

Hardens the Spec-Layer that landed in v3.16+ as a skeleton (NewSpecCmd() in cmd/sin-code) into a production-grade SOTA feature.

Why

The Spec-Layer is the missing link between Learning and Verification. Without it, the Instinct subsystem can drift silently: an Instinct embeds a behavior that the original .spec.md no longer guarantees. With it, every change has a contract that the CI enforces.

What ships in this epic

1. Pre-commit drift detection

A pre-commit hook (scripts/spec-drift-check.sh) that runs on every git commit and:

1. Reads every .spec.md in the repo
2. For each spec, parses the contract: "function X accepts Y, returns Z, raises E"
3. Greps the code for the actual signature
4. Reports any drift as a warning (or error, depending on .sin-code.yml policy)

2. CI gate

Extend lint-and-security/golangci-lint (or a new spec-ci workflow) to run the same check on every PR. A spec drift that the developer didn't fix pre-commit blocks the merge.

3. Self-authoring mode

sin spec author "Add rate limiting to API" runs:

1. A Planner LLM call → generates .spec.md with the contract
2. An Implementer LLM call → writes the code
3. The verify gate → checks spec vs code
4. On mismatch, retry up to 3 times

Acceptance criteria

• scripts/spec-drift-check.sh exits 0 on a clean repo, 1 on drift
• A .sin-code.yml policy key spec.drift: error|warn|off controls the strictness
• sin spec author "<description>" produces a working PR with both spec + code
• Drift detection covers Go signatures, Python signatures (via ast), JSON Schema
• Test coverage for the parser and the drift checker ≥ 80%

Mandates

• M1 (n8n CI): the new spec-ci workflow is n8n-delegated, not direct
• M3 (verify gate): this is the verify-gate upgrade, fully compliant
• M5 (module path): new code lives under cmd/sin-code/internal/spec/

Related

• Issue Gesamtarchitektur & Einbettung in SIN‑Code Die neue Spec‑Layer #122 — the existing "Spec-Layer" parent issue (this is the concrete implementation)
• docs/PRP-WORKFLOW.md — PRPs are how spec-driven changes are tracked
• internal/verify/ — the verify engine is what consumes the spec
• v3.16.0 release notes for the Spec-Layer introduction

Estimated scope

~3000 LOC, 2-3 PRs, 2-3 weeks. Bumps the spec to v3.18.0.