mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Eric Traut
8e69d29521
## Why The TUI still reached through `app-server-client::legacy_core` for thread-name normalization and project-instruction filename details. In particular, checking the TUI's local filesystem for `/init` is incorrect for remote app-server sessions, where the server owns the working directory and instruction discovery. ## What changed - use the instruction source paths supplied by the app server to decide whether `/init` should avoid overwriting project instructions - keep the small thread-name normalization helper local to the TUI - remove the now-unused instruction filename constants, utility module, and other unused `legacy_core` re-exports - make status helper tests independent of concrete instruction filenames ## Verification - `just test -p codex-app-server-client` - `just test -p codex-tui slash_init_skips_when_project_instructions_are_loaded` - `just test -p codex-tui` ran 2,799 tests; 2,797 passed and two unrelated guardian feature-flag tests failed reproducibly in untouched code ### Manual test Started an app server over WebSocket with a remote workspace containing `AGENTS.md`, then connected the TUI using `--remote`. After confirming `thread/start` returned the file in `instructionSources`, deleted `AGENTS.md` and ran `/init` in the existing session. The TUI still reported that project instructions already existed and skipped `/init`. The trace contained no `turn/start` request, confirming the decision came from app-server session state rather than a new client-local filesystem check.
42 lines
1.8 KiB
Markdown
42 lines
1.8 KiB
Markdown
Generate a file named AGENTS.md that serves as a contributor guide for this repository.
|
||
Before writing, check whether AGENTS.md already exists in the current working directory. If it does, do not overwrite or modify it.
|
||
Your goal is to produce a clear, concise, and well-structured document with descriptive headings and actionable explanations for each section.
|
||
Follow the outline below, but adapt as needed — add sections if relevant, and omit those that do not apply to this project.
|
||
|
||
Document Requirements
|
||
|
||
- Title the document "Repository Guidelines".
|
||
- Use Markdown headings (#, ##, etc.) for structure.
|
||
- Keep the document concise. 200-400 words is optimal.
|
||
- Keep explanations short, direct, and specific to this repository.
|
||
- Provide examples where helpful (commands, directory paths, naming patterns).
|
||
- Maintain a professional, instructional tone.
|
||
|
||
Recommended Sections
|
||
|
||
Project Structure & Module Organization
|
||
|
||
- Outline the project structure, including where the source code, tests, and assets are located.
|
||
|
||
Build, Test, and Development Commands
|
||
|
||
- List key commands for building, testing, and running locally (e.g., npm test, make build).
|
||
- Briefly explain what each command does.
|
||
|
||
Coding Style & Naming Conventions
|
||
|
||
- Specify indentation rules, language-specific style preferences, and naming patterns.
|
||
- Include any formatting or linting tools used.
|
||
|
||
Testing Guidelines
|
||
|
||
- Identify testing frameworks and coverage requirements.
|
||
- State test naming conventions and how to run tests.
|
||
|
||
Commit & Pull Request Guidelines
|
||
|
||
- Summarize commit message conventions found in the project’s Git history.
|
||
- Outline pull request requirements (descriptions, linked issues, screenshots, etc.).
|
||
|
||
(Optional) Add other sections if relevant, such as Security & Configuration Tips, Architecture Overview, or Agent-Specific Instructions.
|