|
| 1 | +# CommandLayer Repository Instructions |
| 2 | + |
| 3 | +This repository is part of the CommandLayer protocol stack. |
| 4 | + |
| 5 | +## Repo role |
| 6 | + |
| 7 | +`commandlayer/commandlayer-org` is the public website, documentation, registry, and demo surface for CommandLayer. |
| 8 | + |
| 9 | +This repository owns: |
| 10 | + |
| 11 | +- public website pages |
| 12 | +- protocol documentation presentation |
| 13 | +- registry and claim flows where present |
| 14 | +- verifier/demo pages where hosted on the site |
| 15 | +- public examples and onboarding copy |
| 16 | +- integration documentation |
| 17 | +- site metadata and public trust messaging |
| 18 | + |
| 19 | +This repository does not own CLAS schema truth, core cryptographic semantics, runtime execution policy, SDK internals, MCP transport behavior, governance policy, or commercial runtime internals. |
| 20 | + |
| 21 | +## Hard rules |
| 22 | + |
| 23 | +- Do not guess. |
| 24 | +- Do not publish packages. |
| 25 | +- Do not merge pull requests. |
| 26 | +- Do not document unsupported behavior as supported. |
| 27 | +- Do not claim package publication status unless verified from package metadata and registry evidence. |
| 28 | +- Do not claim verification guarantees that the verifier implementation does not provide. |
| 29 | +- Do not confuse sample/demo data with live verification output. |
| 30 | +- Do not redefine receipt semantics in website copy. |
| 31 | +- Do not introduce placeholders, TODOs, broken links, skipped tests, or hardcoded secrets. |
| 32 | +- Do not change public protocol claims without checking the CLAS stack contract. |
| 33 | + |
| 34 | +## Protocol requirements |
| 35 | + |
| 36 | +Website and documentation behavior MUST align with the canonical stack contract in `commandlayer/clas`: |
| 37 | + |
| 38 | +- canonicalization ID: `json.sorted_keys.v1` |
| 39 | +- hash algorithm: SHA-256 |
| 40 | +- signature algorithm: Ed25519 |
| 41 | +- verifier responses preserve `ok`, `status`, `checks`, and `errors` semantics |
| 42 | +- `VERIFIED` means schema, hash, signature, and signer checks passed |
| 43 | +- invalid or demo-only flows must be labeled accurately |
| 44 | + |
| 45 | +## Before editing |
| 46 | + |
| 47 | +1. Inspect `README.md`, public pages, docs, API routes, registry files, examples, tests, config, and deployment files where present. |
| 48 | +2. Identify whether the change affects public claims, docs, verifier/demo behavior, registry data, API behavior, SEO metadata, or deployment. |
| 49 | +3. Compare protocol claims against the CLAS stack contract and implementation repos. |
| 50 | +4. Make the smallest safe change. |
| 51 | +5. Run build, test, typecheck, lint, and site checks if available. |
| 52 | +6. Report changed files, commands run, results, and remaining risks. |
| 53 | + |
| 54 | +## Documentation rules |
| 55 | + |
| 56 | +- Public docs MUST distinguish specification, implementation, demo, sample, and planned behavior. |
| 57 | +- Public docs MUST NOT say `coming soon`, `TBD`, or similar placeholders. |
| 58 | +- Public docs MUST link to canonical repos when making protocol claims. |
| 59 | +- Package install commands MUST match actual package names and publication status. |
| 60 | +- Verifier demos MUST clearly label sample receipts and tampered receipts. |
| 61 | +- Public registry entries MUST not imply verification or endorsement beyond implemented behavior. |
| 62 | +- Marketing copy MUST not override protocol truth. |
| 63 | + |
| 64 | +## Site/API rules |
| 65 | + |
| 66 | +- API routes MUST validate inputs. |
| 67 | +- API routes MUST handle async errors explicitly. |
| 68 | +- Public endpoints SHOULD be rate-limited where appropriate. |
| 69 | +- Secrets MUST not be exposed in client-side code or generated output. |
| 70 | +- Demo pages MUST not rely on hidden hardcoded production keys as the only verification path. |
| 71 | +- SEO changes MUST not create false protocol claims. |
| 72 | + |
| 73 | +## Test requirements |
| 74 | + |
| 75 | +Changes to docs, verifier pages, API routes, registry pages, or demos SHOULD include checks for: |
| 76 | + |
| 77 | +- build success |
| 78 | +- broken links |
| 79 | +- route availability |
| 80 | +- sample vs live labeling |
| 81 | +- verifier status accuracy |
| 82 | +- API invalid input handling |
| 83 | +- no exposed secrets |
| 84 | +- no unsupported package claims |
| 85 | + |
| 86 | +## Review focus |
| 87 | + |
| 88 | +When reviewing changes, focus on: |
| 89 | + |
| 90 | +- unsupported claims |
| 91 | +- schema or verification drift |
| 92 | +- false VERIFIED language |
| 93 | +- sample/live ambiguity |
| 94 | +- broken documentation links |
| 95 | +- stale package install instructions |
| 96 | +- hardcoded secrets or keys |
| 97 | +- API input validation gaps |
| 98 | +- public pages getting ahead of implementation |
| 99 | +- inconsistencies with governance, CLAS, runtime-core, runtime, agent-sdk, verifyagent, or mcp-server |
| 100 | + |
| 101 | +## Output format |
| 102 | + |
| 103 | +For every task, report: |
| 104 | + |
| 105 | +1. Summary |
| 106 | +2. Files changed |
| 107 | +3. Checks run |
| 108 | +4. Results |
| 109 | +5. Risks remaining |
| 110 | +6. Follow-up recommendations |
0 commit comments