@nomos-arc/arc 0.1.0

package/docs/certificate/cer_enhance_plan.md

@@ -0,0 +1,605 @@
+# Certificate Enhancement Plan — Enterprise Grade
+
+> **Document:** `enhance_plan.md`
+> **Author:** Senior Technical Architect / CEO, nomos-arc.ai
+> **Date:** 2026-04-04
+> **Status:** Approved for Implementation
+> **Scope:** Certificate v2 — Non-Repudiation, Governance Persistence, CI/CD Enforcement, Executive Reporting
+
+---
+
+## Executive Summary
+
+The Certificate of AI Engineering Integrity (v1) establishes tamper-evidence through hash chaining and self-sealing. This is sufficient to prove *internal consistency* but insufficient for enterprise compliance. Three critical gaps remain:
+
+1. **Non-Repudiation**: The certificate proves *what* happened but not *who* vouches for it. Without a digital signature bound to a developer identity, the certificate is an unsigned assertion.
+2. **Governance Persistence**: The `rules_hash` proves rules *existed* at generation time but cannot reproduce them if the original files are deleted or modified. An auditor holding only the certificate has a hash with no content to verify against.
+3. **Passive Artifact**: The certificate is generated but never enforced. Code can be merged without one. In regulated environments, an unenforced control is equivalent to no control.
+
+Addressing these gaps transforms the certificate from a *documentation artifact* into a **cryptographic compliance gate** — the first in the AI-assisted engineering market. This positions nomos-arc.ai as the only tool that provides verifiable, enforceable, identity-bound proof of responsible AI engineering.
+
+**Market impact**: Enterprise procurement in Banking, Healthcare, and Defense requires non-repudiation and CI/CD enforcement as baseline criteria. Without these, the certificate is a differentiator for demos but not for contracts.
+
+---
+
+## 1. Digital Signature Layer (Non-Repudiation)
+
+### 1.1 Problem Statement
+
+The current `certificate_hash` proves the payload has not been modified since generation, but it does not bind the certificate to a human identity. Any process with write access to the certificate file can regenerate a valid `certificate_hash` after tampering with the content. The hash chain is tamper-evident but not tamper-proof without an external trust anchor.
+
+### 1.2 Design
+
+Integrate SSH and GPG signing to produce an identity-bound signature over the `certificate_hash`. The signature block is appended to the certificate payload *after* the self-seal, creating a layered integrity model:
+
+```
+Layer 1: chain_hash         → proves history entry integrity
+Layer 2: certificate_hash   → proves payload integrity (self-seal)
+Layer 3: signature           → proves identity + non-repudiation
+```
+
+### 1.3 Implementation Steps
+
+#### Step 1: Define the `SignatureBlock` schema
+
+```typescript
+interface SignatureBlock {
+  signer: string;                    // e.g., "Ibrahim Magdy <ibrahim@nomos-arc.ai>"
+  method: 'ssh-ed25519' | 'ssh-rsa' | 'gpg';
+  key_fingerprint: string;           // public key fingerprint for audit trail
+  signed_hash: string;               // the certificate_hash that was signed
+  signature: string;                 // base64-encoded detached signature
+  signed_at: string;                 // ISO 8601
+}
+```
+
+The `SignatureBlock` is added as an optional field on `CertificatePayload`. It is *not* included in the `certificate_hash` computation — the signature signs the hash, not the payload. This preserves backward compatibility: unsigned certificates remain valid for v1 verification.
+
+#### Step 2: Implement `arc certificate <task> --sign`
+
+The `--sign` flag triggers the signing flow after certificate generation:
+
+1. **Key discovery**: Check for available signing keys in order of preference:
+   - `ssh-agent` (via `SSH_AUTH_SOCK`): List keys with `ssh-add -L`, select the first ed25519 key.
+   - GPG keyring: Execute `gpg --list-secret-keys --keyid-format=long`, use the first available key.
+   - Explicit key path: `--sign-key <path>` flag for environments without agent.
+
+2. **Signature computation**:
+   - Extract `certificate_hash` value (the hex string after `sha256:`).
+   - For SSH: Write hash to temp file, execute `ssh-keygen -Y sign -f <key> -n nomos-certificate <tempfile>`.
+   - For GPG: Pipe hash to `gpg --detach-sign --armor --local-user <keyid>`.
+
+3. **Block assembly**: Populate `SignatureBlock` with signer identity (from `git config user.name` + `git config user.email`), method, fingerprint, signature output, and timestamp.
+
+4. **Append to certificate**: Add `signature` field to the certificate JSON and write to disk. The `certificate_hash` is *not* recomputed — the signature is outside the seal.
+
+#### Step 3: Implement signature verification in `--verify`
+
+Add a 6th verification check: `signature_validity`.
+
+- If `signature` block is absent: check is `SKIP` (not `FAIL`) — backward compatible.
+- If present: verify that `signed_hash === certificate_hash`, then verify the cryptographic signature using the appropriate tool (`ssh-keygen -Y verify` or `gpg --verify`).
+- Report signer identity and key fingerprint in the check detail.
+
+#### Step 4: Key trust policy (optional, deferred)
+
+For v2, nomos-arc.ai trusts any valid SSH/GPG signature — it proves *who* signed, not *whether they were authorized*. A future `allowed_signers` file (SSH) or trust-db (GPG) integration can restrict signing to approved identities.
+
+### 1.4 Security Analysis
+
+- **Threat mitigated**: An attacker who modifies the certificate and recomputes `certificate_hash` cannot forge a valid signature without the signer's private key.
+- **Key compromise**: If a signing key is compromised, the attacker can produce valid signatures. Mitigation: key rotation policy and fingerprint logging in the certificate allow post-incident audit of which certificates were signed with the compromised key.
+- **Non-repudiation**: The signer cannot deny having signed the certificate — the signature is verifiable against their public key.
+
+---
+
+## 2. Governance Snapshot (Rules Persistence)
+
+### 2.1 Problem Statement
+
+The current certificate stores `rules.files` (file names) and `rules.rules_hash` (SHA-256 of concatenated content). This proves that specific rules *were loaded* during the task lifecycle, but if the rule files are later modified or deleted from the repository, an auditor cannot reconstruct what was enforced. The hash becomes unverifiable against thin air.
+
+### 2.2 Design
+
+Transition from "reference by hash" to "embedded context" by including a compressed summary of the active rules within the certificate. Two strategies, selected by content size:
+
+| Strategy | Condition | Content |
+|---|---|---|
+| **Full embed** | Total rules content < 10 KB | Raw content of each rule file, keyed by filename |
+| **Summary embed** | Total rules content >= 10 KB | First 200 lines per file + SHA-256 per file |
+
+This ensures the certificate is self-contained for audit purposes without unbounded growth.
+
+### 2.3 Implementation Steps
+
+#### Step 1: Extend the `rules` section in `CertificatePayload`
+
+```typescript
+rules: {
+  files: string[];
+  rules_hash: string;
+  // NEW — v2 addition
+  rules_snapshot: {
+    strategy: 'full' | 'summary';
+    content: Record<string, {
+      hash: string;            // per-file SHA-256
+      body: string;            // full content or truncated (first 200 lines)
+      truncated: boolean;      // true if body is not the full file
+    }>;
+    total_size_bytes: number;  // original total size before any truncation
+  };
+};
+```
+
+#### Step 2: Populate during `generate()`
+
+In `CertificateEngine.generate()`, after loading the task state:
+
+1. Read each file listed in `state.context.rules` from disk (resolve paths relative to `rules/` directory).
+2. Compute per-file SHA-256.
+3. If total content size < 10,240 bytes: embed full content, set `strategy: 'full'`.
+4. If >= 10,240 bytes: truncate each file to first 200 lines, set `strategy: 'summary'`, mark `truncated: true`.
+5. Verify that SHA-256 of concatenated *full* content matches `state.context.rules_hash` — if mismatch, warn that rules have been modified since task execution (do not block generation, but add a warning to output).
+
+#### Step 3: Add verification check `rules_integrity`
+
+A 7th verification check (or 6th if signature is absent):
+
+- Recompute `rules_hash` from `rules_snapshot.content` (using full bodies only if `strategy: 'full'`).
+- Compare with `rules.rules_hash`.
+- If strategy is `summary` (truncated), the check can only verify per-file hashes, not the aggregate — mark as `PARTIAL`.
+
+#### Step 4: Handle missing rule files gracefully
+
+If a rule file listed in `state.context.rules` no longer exists on disk at certificate generation time:
+
+- Log a warning: `Rule file "backend.md" no longer exists — embedding from state snapshot`.
+- If the content is recoverable from git history (`git show HEAD:rules/backend.md`), use that.
+- If not recoverable, embed `{ hash: state_hash, body: "[content unavailable — file deleted]", truncated: false }`.
+- This is a **degraded** certificate — the `rules_integrity` check will note the gap.
+
+### 2.4 Security Analysis
+
+- **Threat mitigated**: Post-hoc rule modification to make a non-compliant task appear compliant. With embedded rules, the certificate is self-contained evidence of what was enforced.
+- **Size concern**: The 10 KB threshold prevents certificate bloat. For projects with extensive rule sets, the summary strategy preserves auditability (per-file hashes) while bounding size.
+
+---
+
+## 3. CI/CD Enforcement Gate (The "Hard Gate")
+
+### 3.1 Problem Statement
+
+The certificate is currently generated on-demand and never checked. A developer can merge code without ever running `arc certificate`. In regulated environments, an unenforced control is an audit finding, not a feature.
+
+### 3.2 Design
+
+A GitHub Action (`nomos-gate`) that runs as a required status check on pull requests. It performs four verifications and blocks merge if any fail:
+
+```
+PR opened/updated
+    ↓
+nomos-gate action
+    ├── 1. Certificate exists for this PR's head commit
+    ├── 2. chain_hash is valid
+    ├── 3. Digital signature is valid (if signing is required)
+    └── 4. base_commit matches PR head
+         ↓
+    All pass → ✅ Status check passes
+    Any fail → ❌ Status check fails, merge blocked
+```
+
+### 3.3 Implementation Steps
+
+#### Step 1: Define the GitHub Action (`action.yml`)
+
+```yaml
+name: 'nomos-arc Certificate Gate'
+description: 'Verify AI Engineering Integrity Certificate before merge'
+inputs:
+  certificate-path:
+    description: 'Path to the certificate JSON file'
+    required: false
+    default: 'tasks-management/certificates/*.certificate.json'
+  require-signature:
+    description: 'Require a valid digital signature'
+    required: false
+    default: 'false'
+  allowed-signers:
+    description: 'Path to allowed_signers file (SSH) for identity verification'
+    required: false
+runs:
+  using: 'node20'
+  main: 'dist/gate/index.js'
+```
+
+#### Step 2: Gate logic (`src/gate/index.ts`)
+
+The gate action performs the following sequence:
+
+1. **Certificate discovery**: Glob for `*.certificate.json` files matching the configured path. If no certificate found, fail with `MISSING_CERTIFICATE`.
+
+2. **Parse + schema validation**: Use `CertificateEngine.parse()` to validate JSON structure. Fail with `INVALID_SCHEMA` on Zod errors.
+
+3. **Full verification**: Run `CertificateEngine.verify()` — all 5 (or 7 with new checks) must pass.
+
+4. **Commit binding**: Extract `repository.base_commit` from the certificate. Compare against the PR's head commit SHA (available via `github.event.pull_request.head.sha`). This proves the certificate was generated for *this specific code*, not a different version.
+
+   - **Matching strategy**: The certificate's `base_commit` is the commit the shadow branch forked from, while the PR's head SHA is the latest commit on the branch. The gate should verify that `base_commit` is an ancestor of the PR head commit, or that the PR's commit list includes changes from the shadow branch.
+   - Simplified v1: Verify that `repository.shadow_branch` matches the PR's head branch name. This is weaker but sufficient for MVP.
+
+5. **Signature validation** (if `require-signature: true`):
+   - Check that `signature` block exists in the certificate.
+   - Verify the cryptographic signature using `ssh-keygen -Y verify` or `gpg --verify`.
+   - If `allowed-signers` is provided, verify the signer is in the allowed list.
+
+6. **Result reporting**: Set the GitHub status check result. On failure, post a PR comment with the specific check failures for developer visibility.
+
+#### Step 3: Output annotations
+
+Use `@actions/core` to emit annotations:
+
+```typescript
+core.error('Certificate chain_hash verification failed', {
+  file: certificatePath,
+  title: 'nomos-arc Certificate Gate: CHAIN_HASH_INVALID',
+});
+```
+
+#### Step 4: Configuration in consumer repos
+
+```yaml
+# .github/workflows/nomos-gate.yml
+name: nomos-arc Certificate Gate
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: nomos-arc/nomos-gate@v1
+        with:
+          require-signature: true
+          allowed-signers: .nomos/allowed_signers
+```
+
+#### Step 5: Branch protection integration
+
+Document that the consumer must add `nomos-gate` as a required status check in GitHub branch protection settings. Without this, the action runs but doesn't block.
+
+### 3.4 Security Analysis
+
+- **Threat mitigated**: Merging code without a valid certificate, or using a certificate generated for a different branch/commit.
+- **Bypass risk**: Repository admins can override required status checks. This is a GitHub platform limitation, not a nomos-arc.ai limitation. The certificate's immutable audit trail still records whether the gate was passed legitimately.
+- **Commit binding weakness**: The MVP branch-name matching is weaker than full commit-ancestry verification. A developer could theoretically name a different branch identically. The full commit-ancestry check should be implemented in v2.1.
+
+---
+
+## 4. Human-Centric Reporting (The Executive View)
+
+### 4.1 Problem Statement
+
+CTOs and auditors do not read JSON. The certificate in its current form is machine-readable but not board-ready. A compliance report must be visually professional, printable, and immediately interpretable by non-technical stakeholders.
+
+### 4.2 Design
+
+Implement `arc certificate <task> --format pdf` and `--format html` that render the certificate JSON into a professional compliance report.
+
+### 4.3 Implementation Steps
+
+#### Step 1: Template engine selection
+
+Use a lightweight, zero-native-dependency approach:
+
+| Option | Pros | Cons | Recommendation |
+|---|---|---|---|
+| `handlebars` + `puppeteer` | Full HTML/CSS control, PDF via Chrome headless | Puppeteer is ~400 MB | Only for environments with Chrome |
+| `handlebars` + `@react-pdf/renderer` | React-based PDF, tree-shakeable | JSX dependency | Over-engineered for templates |
+| **`ejs` + `html-pdf-node`** | Lightweight, template-based, Chromium-free | Less CSS control | **Recommended for CLI** |
+| `handlebars` + raw HTML export | Zero new deps for HTML; PDF deferred | No PDF without browser | **Recommended for v2 MVP** |
+
+**Decision**: For v2, implement HTML export using `handlebars` (single dependency, 72 KB). PDF generation via `--format pdf` deferred to v2.1 with `puppeteer` as an optional peer dependency — users who need PDF install it; the CLI stays lightweight.
+
+#### Step 2: Report template structure
+
+```
+┌──────────────────────────────────────────────────┐
+│  nomos-arc.ai — Certificate of AI Engineering        │
+│  Integrity                                       │
+│                                                  │
+│  ┌────────────────────────────────────────────┐  │
+│  │  VERIFICATION STATUS: ✅ VALID             │  │
+│  │  Certificate Hash: sha256:2c624232c...     │  │
+│  │  Generated: 2026-04-04T12:00:00Z           │  │
+│  │  Signed by: Ibrahim Magdy (ssh-ed25519)    │  │
+│  └────────────────────────────────────────────┘  │
+│                                                  │
+│  TASK SUMMARY                                    │
+│  ─────────────────────────────────────────────── │
+│  Task ID:        implement-auth-middleware        │
+│  Status:         approved                         │
+│  Iterations:     2                                │
+│  Final Score:    0.92 / 1.00                      │
+│  Approval:       score_threshold                  │
+│                                                  │
+│  REVIEW TRAIL                                    │
+│  ─────────────────────────────────────────────── │
+│  Version 1:                                       │
+│    Planning: claude (supervised)                   │
+│    Review:   codex → 0.65 (1 high-severity issue) │
+│  Version 2:                                       │
+│    Planning: claude (supervised)                   │
+│    Review:   codex → 0.92 (0 issues)              │
+│                                                  │
+│  GOVERNANCE                                      │
+│  ─────────────────────────────────────────────── │
+│  Rules enforced: global.md, backend.md            │
+│  Rules hash:     sha256:9f86d081884c...           │
+│                                                  │
+│  INTEGRITY                                       │
+│  ─────────────────────────────────────────────── │
+│  Chain algorithm: sha256-sequential               │
+│  Chain hash:      sha256:7d865e959b24...          │
+│  Entries:         4                               │
+│                                                  │
+│  BUDGET                                          │
+│  ─────────────────────────────────────────────── │
+│  Total tokens: 8,600                              │
+│  Estimated cost: $0.02                            │
+│                                                  │
+│  ─────────────────────────────────────────────── │
+│  Generated by nomos-arc@0.1.0                      │
+│  Verify: arc certificate <task> --verify          │
+└──────────────────────────────────────────────────┘
+```
+
+#### Step 3: Implement the rendering pipeline
+
+1. Add `CertificateRenderer` class in `src/core/certificate-renderer.ts`.
+2. Method `renderHTML(certificate: CertificatePayload, verificationResult?: VerificationResult): string`.
+3. Load the Handlebars template from `src/templates/certificate-report.hbs`.
+4. Inject certificate data, computed fields (formatted dates, score percentages, issue counts), and optional verification result.
+5. Return the compiled HTML string.
+
+#### Step 4: Wire into CLI
+
+Extend the `--format` flag to accept `html`:
+
+```typescript
+if (opts.format === 'html') {
+  const renderer = new CertificateRenderer();
+  const result = engine.verify(certificate);
+  const html = renderer.renderHTML(certificate, result);
+  const htmlPath = certPath.replace('.json', '.html');
+  fs.writeFileSync(htmlPath, html, 'utf-8');
+  console.log(`Report saved to: ${htmlPath}`);
+}
+```
+
+#### Step 5: CSS for print
+
+Include a `@media print` stylesheet in the HTML template for direct browser-to-PDF printing. This provides a zero-dependency PDF path: open HTML in browser, print to PDF.
+
+---
+
+## 5. Schema Updates
+
+### 5.1 `CertificatePayload` interface changes (`src/types/index.ts`)
+
+```typescript
+export interface CertificatePayload {
+  // Envelope
+  certificate_version: 1 | 2;           // CHANGED: support v2
+  generated_at: string;
+  generator: string;
+
+  // Subject (unchanged)
+  task_id: string;
+  task_status: TaskStatus;
+  created_at: string;
+  completed_at: string;
+
+  // Repository provenance (unchanged)
+  repository: {
+    base_commit: string;
+    shadow_branch: string;
+    branch_status: 'active' | 'merged' | 'discarded';
+  };
+
+  // AI provenance (unchanged)
+  models: {
+    planner: string;
+    reviewer: string;
+  };
+
+  // Governance — EXTENDED
+  rules: {
+    files: string[];
+    rules_hash: string;
+    rules_snapshot?: {                   // NEW — v2
+      strategy: 'full' | 'summary';
+      content: Record<string, {
+        hash: string;
+        body: string;
+        truncated: boolean;
+      }>;
+      total_size_bytes: number;
+    };
+  };
+
+  // Review trail (unchanged)
+  iterations: CertificateIteration[];
+  final_review: {
+    score: number;
+    summary: string;
+    issues: ReviewIssue[];
+    approval_reason: 'score_threshold' | 'max_iterations_reached';
+  };
+
+  // Resources (unchanged)
+  budget: {
+    total_tokens: number;
+    estimated_cost_usd: number;
+    token_breakdown: { input_tokens: number; output_tokens: number };
+  };
+
+  // Integrity (unchanged)
+  integrity: {
+    chain_hash: string;
+    entry_hashes: string[];
+    canonical_entries: string[];
+    chain_algorithm: 'sha256-sequential';
+  };
+
+  // Self-seal (unchanged)
+  certificate_hash: string;
+
+  // Digital signature — NEW (v2, optional)
+  signature?: SignatureBlock;
+}
+
+// NEW interface
+export interface SignatureBlock {
+  signer: string;
+  method: 'ssh-ed25519' | 'ssh-rsa' | 'gpg';
+  key_fingerprint: string;
+  signed_hash: string;
+  signature: string;
+  signed_at: string;
+}
+```
+
+### 5.2 Zod schema updates (`src/core/certificate.ts`)
+
+- Add `SignatureBlockSchema` as an optional field on `CertificatePayloadSchema`.
+- Add `RulesSnapshotSchema` within the `rules` object.
+- Update `certificate_version` from `z.literal(1)` to `z.union([z.literal(1), z.literal(2)])`.
+- All new fields are optional to maintain backward compatibility with v1 certificates.
+
+### 5.3 Verification checks update
+
+| # | Check | v1 | v2 |
+|---|---|---|---|
+| 1 | `status_validity` | Yes | Yes |
+| 2 | `review_completeness` | Yes | Yes |
+| 3 | `certificate_hash` | Yes | Yes |
+| 4 | `chain_hash` | Yes | Yes |
+| 5 | `entry_hash_consistency` | Yes | Yes |
+| 6 | `signature_validity` | - | Yes (SKIP if unsigned) |
+| 7 | `rules_integrity` | - | Yes (PARTIAL if summary) |
+
+---
+
+## 6. Security Analysis
+
+### 6.1 Threat Model
+
+| Threat | Pre-Enhancement | Post-Enhancement |
+|---|---|---|
+| **Payload tampering** (modify score after generation) | Detected via `certificate_hash` | Detected via `certificate_hash` + signature prevents re-seal |
+| **History rewriting** (alter iteration data) | Detected via `chain_hash` | Detected via `chain_hash` + signature prevents re-seal |
+| **Identity spoofing** (claim someone else generated it) | Not addressed | Signature binds to SSH/GPG key identity |
+| **Rule modification** (change rules after task completion) | Detected via `rules_hash` but unverifiable without originals | Full rules embedded — self-contained verification |
+| **Certificate absence** (merge without certificate) | Not enforced | CI/CD gate blocks merge |
+| **Certificate reuse** (use cert from different branch) | Not detected | `base_commit` binding in CI/CD gate |
+| **Shadow AI** (using unapproved AI tools outside nomos-arc.ai) | Not addressed | Certificate absence in CI/CD blocks unauthorized AI work from merging without a process record |
+
+### 6.2 Residual Risks
+
+1. **Key compromise**: A compromised signing key allows forgery. Mitigation: key fingerprint logging enables post-incident audit.
+2. **Admin override**: GitHub admins can bypass required status checks. Mitigation: the certificate audit trail persists independently.
+3. **Offline tampering**: A developer with repo access can craft a fake certificate with valid structure. Mitigation: digital signature makes this computationally infeasible without the private key.
+4. **Rule file unavailability**: If rule files are deleted before certificate generation, the snapshot will be incomplete. Mitigation: attempt git history recovery; flag as degraded.
+
+---
+
+## 7. Success Metrics
+
+### 7.1 Definition: Valid Enterprise Certificate
+
+A certificate is "Enterprise Valid" when ALL of the following hold:
+
+| Criterion | Verification Method |
+|---|---|
+| Task status is `approved` or `merged` | `status_validity` check |
+| Final review exists with score and summary | `review_completeness` check |
+| Payload has not been modified since generation | `certificate_hash` check |
+| History entries have not been tampered with | `chain_hash` check |
+| Entry hashes are consistent across data structures | `entry_hash_consistency` check |
+| Certificate is signed by an identified developer | `signature_validity` check |
+| Governance rules are embedded and hash-consistent | `rules_integrity` check |
+| Certificate's base_commit is ancestor of merge target | CI/CD gate `commit_binding` check |
+
+### 7.2 Implementation Success Criteria
+
+| Metric | Target |
+|---|---|
+| All existing 26 tests continue to pass (backward compat) | 100% |
+| New tests for signature, rules snapshot, and gate logic | >= 30 additional tests |
+| v1 certificates verify correctly under v2 engine | Yes |
+| v2 certificates with signature fail verification if tampered | Yes |
+| CI/CD gate blocks merge when certificate is missing | Yes |
+| CI/CD gate blocks merge when signature is invalid | Yes (when `require-signature: true`) |
+| HTML report renders correctly for all certificate versions | Yes |
+| No new runtime dependencies for core certificate engine | Yes (signature uses system SSH/GPG) |
+| Single new dependency for HTML rendering (`handlebars`) | Yes |
+
+---
+
+## 8. Implementation Priority and Sequencing
+
+```
+Phase 2a (Week 1-2): Governance Snapshot
+  └── Lowest risk, highest audit value, no external dependencies
+       ├── Extend CertificatePayload schema
+       ├── Implement rules reading + embedding in generate()
+       ├── Add rules_integrity verification check
+       └── Tests: snapshot strategies, truncation, missing files
+
+Phase 2b (Week 2-3): Digital Signature Layer
+  └── Requires system SSH/GPG — integration testing needed
+       ├── Implement SignatureBlock and --sign flag
+       ├── SSH signing via ssh-keygen
+       ├── GPG signing via gpg CLI
+       ├── Add signature_validity verification check
+       └── Tests: sign/verify round-trip, tampered signature, missing key
+
+Phase 2c (Week 3-4): CI/CD Enforcement Gate
+  └── Depends on 2a + 2b for full gate logic
+       ├── Create GitHub Action (nomos-gate)
+       ├── Implement certificate discovery + verification
+       ├── Implement commit binding check
+       ├── Integration tests with mock GitHub context
+       └── Documentation: consumer repo setup
+
+Phase 2d (Week 4): Executive Reporting
+  └── Independent of 2a-2c, can be parallelized
+       ├── Add handlebars dependency
+       ├── Create HTML template
+       ├── Implement CertificateRenderer
+       ├── Wire --format html into CLI
+       └── Tests: rendering with all certificate variants
+```
+
+---
+
+## 9. Conclusion
+
+These four enhancements transform the Certificate from a proof-of-concept into enterprise compliance infrastructure. The sequencing prioritizes audit value (governance snapshot) before cryptographic complexity (signatures) before enforcement (CI/CD gate), with reporting parallelized independently.
+
+Upon completion, nomos-arc.ai will be the only AI engineering tool that provides:
+- **Identity-bound** proof of responsible AI usage (signature)
+- **Self-contained** governance evidence (rules snapshot)
+- **Enforced** compliance gates (CI/CD action)
+- **Board-ready** reporting (HTML/PDF export)
+
+The certificate becomes the artifact that closes the deal in enterprise procurement.
+
+```
+arc certificate <task> --sign      → The signed proof.
+arc certificate <task> --verify    → The full verification.
+arc certificate <task> --format html → The executive report.
+nomos-gate (GitHub Action)          → The hard gate.
+```