Repository navigation
feat: executable offline Ed25519 permit-to-evidence acceptance demonstration - #74
Conversation
…cation walkthrough
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 30 |
| Duplication | 0 |
AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.
TIP This summary will be updated as you push new changes.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
Pull Request Overview
The scope-mismatch gate reuses a permit after successful consumption, so replay detection may occur before parameter validation. This means the demonstration does not independently prove parameter enforcement and can fail its own acceptance sequence. A fresh permit should be used for that gate.
The installed-command workflow is not covered by the current tests, leaving one acceptance scenario unverified.
Test suggestions
- Run the complete seven-gate scenario and verify every gate passes.
- Verify valid permit execution invokes the built-in echo behavior.
- Verify JSON CLI output is parseable and explicitly non-production.
- Verify human-readable CLI output includes every gate.
- Verify a failed gate produces a nonzero exit code.
- Verify exception contents and sensitive values are redacted.
- Verify evidence restoration into a fresh kernel preserves replay denial.
- Verify the installed CLI works in a subprocess/environment matching the documented installation flow.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify the installed CLI works in a subprocess/environment matching the documented installation flow.
TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback
| kernel.submit(_request("unapproved-parameters", text="unapproved"), | ||
| permit_token=permit), | ||
| Decision.DENY, "PARAMS_MISMATCH") |
There was a problem hiding this comment.
🔴 HIGH RISK
Use a fresh, otherwise-valid permit for the changed-parameter request, preserving the original permit for the successful execution and replay gates.
TIP React 👍 if this review is right, or reply with what's wrong and how it could be better to help improve the reviewer.
| shards-kernel demo --json | ||
| ``` | ||
|
|
||
| The command is **non-financial** and deterministic. It uses a real Ed25519 |
There was a problem hiding this comment.
⚪ LOW RISK
Suggestion: Describe the scenario as behaviorally reproducible rather than deterministic, or use fixed cryptographic inputs for this non-production harness.
TIP React 👍 if this review is right, or reply with what's wrong and how it could be better to help improve the reviewer.
Objective — reproducible offline acceptance demo for #69
A developer can
python -m pip install -e ".[crypto]"and runshards-kernel demo --jsonwithout writing custom glue. The scenario exercises seven real local governance decisions:Every gate is individually asserted; command returns non-zero on failure, redacts exception details and never reports
production_ready=true. Includes unit tests and operator documentation.Proof required
Explicit limitations
The issuer key is ephemeral in the same demo process, clock virtual, ledger copied in-memory, and transport not an independently authenticated remote MCP connection. These are production blockers under #68/#69/#63, not claims that those issues are solved. No wallets, financial operations or network calls.