Skip to content

docs(agents): replace Platform Context with public build-agent rules #44

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
yakimoto wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(agents): replace Platform Context with public build-agent rules #44

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 46 additions & 9 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,18 +30,55 @@ Apply the four grounding rules from [`wave-foundation/frameworks/platform-regist

Report vulnerabilities via the [Security Policy](https://github.com/wave-av/.github/blob/main/SECURITY.md) (security@wave.online) — never in a public issue.

# Platform Context
## Public Repository Rules for Build Agents

You are working inside the WAVE platform (wave-av org, 157 repos). Before acting:
This repository is public. Anything written here — PR titles, PR bodies, commit messages,
comments, issues, and file content — is permanent and world-readable, including after edits

@cubic-dev-ai cubic-dev-ai Bot Sep 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: Do not state that all public text remains world-readable after edits or deletes. Qualify this as content that may persist through edit history, notifications, forks, caches, or repository history so agents do not rely on an inaccurate absolute claim.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At AGENTS.md, line 36:

<comment>Do not state that all public text remains world-readable after edits or deletes. Qualify this as content that may persist through edit history, notifications, forks, caches, or repository history so agents do not rely on an inaccurate absolute claim.</comment>

<file context>
@@ -30,18 +30,55 @@ Apply the four grounding rules from [`wave-foundation/frameworks/platform-regist
 
-You are working inside the WAVE platform (wave-av org, 157 repos). Before acting:
+This repository is public. Anything written here — PR titles, PR bodies, commit messages,
+comments, issues, and file content — is permanent and world-readable, including after edits
+or deletes. Treat every write as if a competitor, reporter, or attacker is reading it, because
+they can.
</file context>

or deletes. Treat every write as if a competitor, reporter, or attacker is reading it, because
they can.
Comment on lines +35 to +38

@codeant-ai codeant-ai Bot Sep 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: The claim that edited or deleted PR text, comments, issues, and files remain world-readable is false and may cause agents to make incorrect disclosure decisions. [possible bug]

Assessment: 🟠 Major · 🔁 Occurrence: Often

Use CodeAnt Skill Fix in Cursor Fix in VSCode Claude

Prompt for AI Agent 🤖 
This is a comment left during a code review.

**Path:** AGENTS.md
**Line:** 35:38
**Comment:**
	*Possible Bug: The claim that edited or deleted PR text, comments, issues, and files remain world-readable is false and may cause agents to make incorrect disclosure decisions.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
👍 | 👎


1. **The registry is the SSOT.** Query it via `@wave-av/registry-sdk` or the REST API at `https://goqtrxgdmaqojmixradj.supabase.co/rest/v1/<table>`. Tables: models, tools, vendors, products (25+ with data planes), deliverables, tests, prose, usage_logs.
2. **Five physics laws gate everything** in CI: gauge-invariance (no raw slug), frame-independence (scores inherited), conservation-of-declaration (four renderings), entropy-monotonicity (nothing unregistered), token-budget-conservation.
3. **The full fleet map** lives at `governance/plans/session-deliverable-registry/PLATFORM-MAP.md` in claude-workstation (157 repos by kind: core/spoke/ssot/tool/sdk).
4. **The 24-axis model taxonomy** lives at `wave-foundation/frameworks/model-routing/champions.json` (calibrated_at 2026-08-24).
5. **The inference pool** runs on our rigs at `http://<fleet-internal-address>:8800/v1` (internal, $0). Frontier fallback via openrouter/anthropic. The rail field on models tracks internal vs customer.
6. **The voice laws**: no em-dashes, every word earns its place, short words over long, active voice, receipt over adjective. Enforced by voice-gate.mjs.
7. **The test-matrix**: every shipped artifact carries unit/integration/smoke/e2e/probe receipts in the tests table. No test, no ship.
Before writing anything, apply these rules:

1. **Write for strangers.** Every title, message, and doc must make sense to an outside
developer and contain only what an outside developer should know. Ask: would this sentence
mean anything to someone who has never seen the private side of this project?

2. **No internal identifiers.** Never paste an internal ticket or tracking code, a decision
record id, a gate or scorecard name, an internal workstream or plan id, or a reference to an
internal build or process-automation tool. Describe the user-facing change (for example,
"fix canary marker matching"), never the internal ticket that asked for it.

3. **No internal topology.** Never name a private repository, an internal hostname or
subdomain, a staging/dev/preview environment, an internal tool, or an internal document
path. Even a bare cross-reference to a private repo is still naming it on a public surface —
describe the dependency in product terms or leave it out.

4. **No approval status.** Never describe who approves what, what is decided versus pending, a
confidence score, or that a change is waiting on someone's sign-off. Public PRs and issues
should stand on their own technical merits.

5. **No internal operations detail.** Never describe an internal automation contract, a

@cubic-dev-ai cubic-dev-ai Bot Sep 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The new rules (2, 3, 5) ban naming internal tools and describing secrets infrastructure, but the unchanged GUIDELINES section in this same file still names dpg.mjs, lattice-init, and Doppler. Agents get directly conflicting instructions, and the file keeps publishing internal tooling names on a public surface, which is the exact outcome this PR is meant to remove. Replace the tool names with generic wording, e.g. "secrets are injected at build time and never stored in git," in the GUIDELINES bullet and drop the lattice-init attribution comments.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At AGENTS.md, line 60:

<comment>The new rules (2, 3, 5) ban naming internal tools and describing secrets infrastructure, but the unchanged GUIDELINES section in this same file still names dpg.mjs, lattice-init, and Doppler. Agents get directly conflicting instructions, and the file keeps publishing internal tooling names on a public surface, which is the exact outcome this PR is meant to remove. Replace the tool names with generic wording, e.g. "secrets are injected at build time and never stored in git," in the GUIDELINES bullet and drop the lattice-init attribution comments.</comment>

<file context>
@@ -30,18 +30,55 @@ Apply the four grounding rules from [`wave-foundation/frameworks/platform-regist
+   confidence score, or that a change is waiting on someone's sign-off. Public PRs and issues
+   should stand on their own technical merits.
+
+5. **No internal operations detail.** Never describe an internal automation contract, a
+   permission rule, a secrets inventory, review-bot internals, an internal briefing document, a
+   local checkout or working-directory path, a session or lane identifier, or CI internals
</file context>

permission rule, a secrets inventory, review-bot internals, an internal briefing document, a
local checkout or working-directory path, a session or lane identifier, or CI internals
beyond what any ordinary open-source project would publish.

6. **No people.** No personal names tied to a process decision ("X approved this", "per X's
directive"), and no personal email addresses anywhere. Use this project's bot or no-reply
identity for commit authorship.

7. **No security internals.** Report vulnerabilities privately per this repo's SECURITY.md —
never describe incident details, after-action reviews, or how a fix was rolled out in
public text. Naming a public CVE in a routine dependency bump is fine.

8. **No secrets.** Never write a key, token, or credential into any public surface — not even
an "example" one that looks plausible. Secret scanning may catch it, but you are the first
line of defense.

9. **If it can't be described without an internal fact, it isn't a public change.** Say so and
stop, and route the work through the appropriate internal channel instead. Don't launder the
fact into a vague euphemism — just don't publish it.

**When in doubt, treat it as internal.** Ask before publishing anything borderline.
## CONTENTS
Comment on lines +81 to 82

@gitar-bot gitar-bot Bot Sep 12, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Quality: Missing blank line before ## CONTENTS heading

The new closing line 'When in doubt, treat it as internal...' runs directly into the ## CONTENTS heading with no blank line separating them, unlike every other section boundary in this file (e.g. lines 14, 20, 28, 32 all have a blank line before the next heading). Some Markdown renderers will not render the heading correctly without a preceding blank line. Add a blank line after line 81.

Was this helpful? React with 👍 / 👎


companion-module-wave
Expand Down
Loading