You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Keep zero-byte rule assets wired, remove fallback injected prose, normalize execution policy across autonomous launch paths, enforce provider account login for containers, and reduce Windows CI coverage to the platform/provider matrix while retaining full Linux and macOS suites.
Copy file name to clipboardExpand all lines: .design/first-class-codex-provider-support.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -309,7 +309,7 @@ The existing init and kickoff unit suites become provider matrices. New fixture
309
309
310
310
## Implementation amendments
311
311
312
-
The bundled Markdown rule surfaces remain installed and wired into `UserPromptSubmit`, `SubagentStart`, session restoration, kickoff guidance, manifest tracking, drift checks, and `rules.local` overrides. Every bundled file under `.crosslink/rules/` and `resources/crosslink/rules/` is intentionally zero bytes. Initialization and updates preserve those empty compatibility files instead of deleting the loader or treating emptiness as damage.
312
+
The bundled Markdown rule surfaces remain installed and wired into `UserPromptSubmit`, `SubagentStart`, session restoration, kickoff guidance, manifest tracking, drift checks, and `rules.local` overrides. Every bundled file under `.crosslink/rules/` and `resources/crosslink/rules/` is intentionally zero bytes. Initialization and updates preserve the active rule files and every loader connection while changing only their bundled contents to empty files.
313
313
314
314
The native-web boundary is implemented by a fixed pre-web notice and provider context hooks. It performs no network request, page download, content rewrite, keyword filter, bot-detector workaround, or API-key exchange. The retired safe-fetch server, dependency, registration, sanitization data, and Anthropic trigger are absent.
docker run --rm -v "$volume:/home/agent/.${provider}" --entrypoint sh crosslink-agent:pr-smoke -c 'printf refreshed > "$1/session-state"' sh "/home/agent/.${provider}"
283
+
state="$(docker run --rm -v "$volume:/home/agent/.${provider}" --entrypoint sh crosslink-agent:pr-smoke -c 'cat "$1/session-state"' sh "/home/agent/.${provider}")"
284
+
test "$state" = refreshed
285
+
if [ "$provider" = codex ]; then
286
+
status_command='codex login status'
287
+
else
288
+
status_command='claude auth status'
289
+
fi
290
+
status="$(docker run --rm -v "$volume:/home/agent/.${provider}" crosslink-agent:pr-smoke sh -c "$status_command" 2>&1 || true)"
291
+
if printf '%s' "$status" | grep -E 'sk-[A-Za-z0-9]|ANTHROPIC_API_KEY|OPENAI_API_KEY|CODEX_API_KEY'; then
292
+
echo 'Provider status exposed key-shaped account data.' >&2
293
+
exit 1
294
+
fi
295
+
docker volume rm "$volume" >/dev/null
296
+
if docker volume inspect "$volume" >/dev/null 2>&1; then
297
+
echo "Provider volume was not removed: $volume" >&2
@@ -460,71 +457,7 @@ def build_reminder(languages, project_tree, dependencies, language_rules, global
460
457
461
458
462
459
463
-
global_section=""
464
-
ifglobal_rules:
465
-
global_section=f"\n{global_rules}\n"
466
-
else:
467
-
468
-
global_section=f"""
469
-
### Pre-Coding Grounding (PREVENT HALLUCINATIONS)
470
-
Before writing code that uses external libraries, APIs, or unfamiliar patterns:
471
-
1. **VERIFY IT EXISTS**: Use WebSearch to confirm the crate/package/module exists and check its actual API
472
-
2. **CHECK THE DOCS**: Fetch documentation to see real function signatures, not imagined ones
473
-
3. **CONFIRM SYNTAX**: If unsure about language features or library usage, search first
474
-
4. **USE LATEST VERSIONS**: Always check for and use the latest stable version of dependencies (security + features)
475
-
5. **NO GUESSING**: If you can't verify it, tell the user you need to research it
476
-
477
-
Examples of when to search:
478
-
- Using a crate/package you haven't used recently → search "[package] [language] docs {current_year}"
479
-
- Uncertain about function parameters → search for actual API reference
480
-
- New language feature or syntax → verify it exists in the version being used
481
-
- System calls or platform-specific code → confirm the correct API
482
-
- Adding a dependency → search "[package] latest version {current_year}" to get current release
483
-
484
-
### General Requirements
485
-
1. **NO STUBS - ABSOLUTE RULE**:
486
-
- NEVER write `TODO`, `FIXME`, `pass`, `...`, `unimplemented!()` as implementation
487
-
- NEVER write empty function bodies or placeholder returns
488
-
- NEVER say "implement later" or "add logic here"
489
-
- If logic is genuinely too complex for one turn, use `raise NotImplementedError("Descriptive reason: what needs to be done")` and create a crosslink issue
490
-
- The PostToolUse hook WILL detect and flag stub patterns - write real code the first time
491
-
2. **NO DEAD CODE**: Discover if dead code is truly dead or if it's an incomplete feature. If incomplete, complete it. If truly dead, remove it.
492
-
3. **FULL FEATURES**: Implement the complete feature as requested. Don't stop partway or suggest "you could add X later."
493
-
4. **ERROR HANDLING**: Proper error handling everywhere. No panics/crashes on bad input.
494
-
5. **SECURITY**: Validate input, use parameterized queries, no command injection, no hardcoded secrets.
495
-
6. **READ BEFORE WRITE**: Always read a file before editing it. Never guess at contents.
496
-
497
-
### Conciseness Protocol
498
-
Minimize chattiness. Your output should be:
499
-
- **Code blocks** with implementation
500
-
- **Tool calls** to accomplish tasks
501
-
- **Brief explanations** only when the code isn't self-explanatory
502
-
503
-
NEVER output:
504
-
- "Here is the code" / "Here's how to do it" (just show the code)
505
-
- "Let me know if you need anything else" / "Feel free to ask"
506
-
- "I'll now..." / "Let me..." (just do it)
507
-
- Restating what the user asked
508
-
- Explaining obvious code
509
-
- Multiple paragraphs when one sentence suffices
510
-
511
-
When writing code: write it. When making changes: make them. Skip the narration.
512
-
513
-
### Large File Management (500+ lines)
514
-
If you need to write or modify code that will exceed 500 lines:
515
-
1. Create a parent issue for the overall feature: `crosslink issue create "<feature name>" -p high`
516
-
2. Break down into subissues: `crosslink issue subissue <parent_id> "<component 1>"`, etc.
517
-
3. Inform the user: "This implementation will require multiple files/components. I've created issue #X with Y subissues to track progress."
518
-
4. Work on one subissue at a time, marking each complete before moving on.
519
-
520
-
### Context Window Management
521
-
If the conversation is getting long OR the task requires many more steps:
522
-
1. Create a crosslink issue to track remaining work: `crosslink issue create "Continue: <task summary>" -p high`
523
-
2. Add detailed notes as a comment: `crosslink issue comment <id> "<what's done, what's next>"`
524
-
3. Inform the user: "This task will require additional turns. I've created issue #X to track progress."
525
-
526
-
Use `crosslink session work <id>` to mark what you're working on.
0 commit comments