Harden TTP protocol MVP

.github/workflows/ci.yml

@@ -8,7 +8,7 @@ on:
 
 jobs:
   verify:
-    name: Demo and Tests
+    name: CLI, Examples, and Tests
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
@@ -17,8 +17,14 @@ jobs:
         with:
           node-version: 20
 
+      - name: Show CLI version
+        run: npm run ttp -- version
+
+      - name: Check TTP examples
+        run: npm run check:examples
+
       - name: Run local adoption demo
         run: npm run demo
 
-      - name: Run trust-routing tests
-        run: npm run test:trust-routing
+      - name: Run tests
+        run: npm test

ASSESSMENT.md

@@ -0,0 +1,49 @@
+# Repository Assessment
+
+## Current Maturity Level
+
+TTP is a promising protocol project in draft/MVP stage. After this update, the repo is more credible as an open-source protocol foundation, but it is not yet recommended for production security enforcement.
+
+## Strengths
+
+- Original protocol positioning around trust decay, proof-based authority, and trust transfer.
+- Clear enterprise relevance for AI agents, non-human identities, CI/CD, service accounts, and API workflows.
+- Good fit as a trust expression layer beneath runtime authority systems.
+- Initial examples, CLI scaffold, tests, and docs now make the project easier to evaluate.
+- Apache 2.0 licensing supports open-source adoption.
+
+## Gaps
+
+- Parser is intentionally minimal and not a complete grammar implementation.
+- Proof model is `cleartext-dev`; signed and ZKP modes are future work.
+- Delegation syntax exists, but delegation evaluation is not complete.
+- Issuer registry and signed claim validation are not implemented.
+- Runtime enforcement requires RAP, Execution Exchange, gateway, or CI integrations.
+- Conformance tests need expansion before independent implementations can rely on the spec.
+
+## Risks
+
+- Overclaiming could damage enterprise credibility if production readiness is implied too early.
+- Trust scores can be misunderstood as universal rather than scoped and time-bound.
+- Weak issuer validation would undermine the protocol in production deployments.
+- Runtime bypass remains the central integration risk.
+- Clock and replay protections need careful design before production use.
+
+## Next Milestones
+
+1. Complete grammar parser and AST conformance fixtures.
+2. Implement signed trust claims and issuer registry prototype.
+3. Add delegation evaluator with scope, expiration, and max-score enforcement.
+4. Define RAP and SCIM-RE mapping fixtures.
+5. Publish security review checklist and failure-mode tests.
+
+## Scores
+
+| Area | Score | Notes |
+| --- | ---: | --- |
+| Protocol originality | 9/10 | Strong differentiated thesis around live, decaying trust. |
+| Enterprise relevance | 8/10 | Clear fit for NHI, agent, workflow, and runtime authority problems. |
+| Implementation maturity | 4/10 | MVP scaffold exists, but production semantics are incomplete. |
+| Security documentation | 6/10 | Threat model and security policy now exist; hardening remains. |
+| Open-source readiness | 7/10 | Better README, governance, examples, CI, and contribution path. |
+| Overall enterprise readiness | 5/10 | Credible for review and prototyping, not enforcement production. |

GOVERNANCE.md

@@ -0,0 +1,47 @@
+# Governance
+
+## Project Purpose
+
+TTP exists to define a portable trust grammar for autonomous execution: trust claims, authority context, delegation, proof requirements, and decay. It should remain interoperable and independent from any single commercial control plane.
+
+## Maintainer Model
+
+Maintainers are responsible for protocol clarity, implementation quality, security review, release integrity, and contributor onboarding.
+
+Security-sensitive areas require maintainer review:
+
+- Parser and evaluator behavior.
+- Trust scoring and decay.
+- Proof modes.
+- Delegation semantics.
+- Runtime integration contracts.
+- Cryptographic verification.
+
+## RFC Process
+
+Protocol changes should use an RFC when they alter grammar, object model, evaluation semantics, proof modes, or compatibility.
+
+An RFC should include:
+
+- Problem statement.
+- Proposed change.
+- Syntax or data model impact.
+- Security considerations.
+- Compatibility and migration notes.
+- Alternatives considered.
+
+## Versioning
+
+Implementation packages use semantic versioning. Protocol grammar uses explicit protocol versions. Backward-incompatible grammar changes require migration notes and conformance fixture updates.
+
+## Compatibility Policy
+
+Draft versions may change. Once a stable version is declared, conforming evaluators should continue accepting compatible prior documents or provide clear migration errors.
+
+## Security Review Process
+
+Changes touching trust semantics should include tests for invalid input, expired trust, insufficient score, unsupported proof modes, and unsafe references. Cryptographic changes require dedicated review before release.
+
+## Contribution Review Expectations
+
+PRs should be focused, documented, and testable. Maintainers may ask for smaller changes when a PR mixes protocol semantics, implementation changes, and documentation updates.

MVP.md

@@ -0,0 +1,62 @@
+# TTP MVP
+
+The first usable TTP implementation should be small, testable, and buildable in 30 days. It should prove the core protocol loop without claiming production security.
+
+## MVP Includes
+
+- Parse `.ttp` files.
+- Validate core syntax.
+- Build an AST/object model.
+- Evaluate static trust score.
+- Evaluate trust decay over time.
+- Evaluate threshold condition.
+- Output JSON evaluation result.
+- Support `cleartext-dev` proof mode.
+- Include at least three examples.
+- Include CLI commands.
+
+## MVP Excludes
+
+- Production ZKP.
+- Distributed trust network.
+- Blockchain anchoring.
+- Full policy marketplace.
+- Complete FrontDesk integration.
+- Cross-enterprise trust routing.
+- Production issuer registry.
+- Production runtime enforcement.
+
+## CLI Commands
+
+```bash
+npm run ttp -- check examples/01-basic-agent.ttp
+npm run ttp -- eval examples/02-trust-decay.ttp --subject agent:invoice_reviewer --at now
+npm run ttp -- version
+```
+
+## Acceptance Criteria
+
+- `ttp check examples/01-basic-agent.ttp` succeeds.
+- `ttp eval examples/02-trust-decay.ttp --subject agent:invoice_reviewer --at now` returns JSON.
+- Tests pass in CI.
+- Invalid syntax returns useful errors.
+- Expired trust returns failed evaluation.
+- Decayed trust below threshold returns failed evaluation.
+- Threshold met returns valid evaluation.
+
+## Initial Examples
+
+- `examples/01-basic-agent.ttp`
+- `examples/02-trust-decay.ttp`
+- `examples/03-threshold-proof.ttp`
+- `examples/04-delegated-trust.ttp`
+- `examples/05-frontdesk-authority-context.ttp`
+
+## Buildable 30-Day Plan
+
+| Week | Work |
+| --- | --- |
+| 1 | Parser, AST, syntax errors, examples. |
+| 2 | Trust decay evaluator and threshold evaluator. |
+| 3 | CLI, JSON output, fixture tests, CI. |
+| 4 | Spec cleanup, security review, contributor docs, conformance fixtures. |