| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 4 | 0% |
| Commands | 0 | 0 | 4 | 0% |
| Section tags | 1 | 1 | 2 | 25% |
What each file covers
Sections
0 shared · 1 only in A · 4 only in B- − Agent Guidance For `/work`
- + OpenSpec Test Guidance
- + Running Tests
- + Cross-Platform Paths
- + Path Canonicalization
Commands
0 shared · 0 only in A · 4 only in B- + pnpm exec vitest run test/path/to/file.test.ts
- + pnpm exec vitest run test/path/to/file.test.ts -t "case name"
- + pnpm test
- + pnpm run build
Section tags
1 shared · 1 only in A · 2 only in B- − agent-behaviour
- + build
- + test
- code-style
Line diff
Fission-AI/OpenSpec · openspec/work/AGENTS.md
@@ −1 @@
1# Agent Guidance For `/work`
2
3When working in this directory, use a product-facing lens first.
4
5Start from how the work is experienced by users, not from the internal command
6or file structure. In this product there are two users:
7
8- Humans: they usually do OpenSpec work by prompting agents. They may run shell
9 commands for interactive setup or one-off actions, but prompts are the normal
10 interface.
11- Agents: they need clear intent, discoverable state, unambiguous next actions,
12 and enough structured output to act safely.
13
14Good human UX is usually good agent UX. A flow that is easy for a human to ask
15for and understand is usually easier for an agent to execute, verify, and
16explain.
17
18For roadmap or slice exploration:
19
20- Describe the user-facing flow before the internal implementation.
21- Ask what the human sees, asks for, approves, or corrects.
22- Ask what the agent must discover, decide, execute, and report back.
23- Ground reasoning in the current repo behavior before proposing new shape.
24- Treat shell commands as supporting mechanics, not the primary product story.
25- Prefer concrete workflows over abstract model language.
26
27When an answer gets confusing, reframe it as:
28
29```text
30What does the human want?
31What does the agent need to know?
32Where does the work live?
33What changes on disk?
34How does the user know it worked?
35```
36
Fission-AI/OpenSpec · test/AGENTS.md
@@ +1 @@
1# OpenSpec Test Guidance
2
3Applies to tests under `test/`.
4
5## Running Tests
6
7- Focused file: `pnpm exec vitest run test/path/to/file.test.ts`
8- Focused case: `pnpm exec vitest run test/path/to/file.test.ts -t "case name"`
9- Full suite: `pnpm test`
10- Run `pnpm run build` before focused CLI tests when implementation changes may leave `dist/` stale.
11
12## Cross-Platform Paths
13
14- Do not hard-code Unix path separators in CLI output expectations unless the implementation intentionally emits POSIX paths.
15- For filesystem paths, build expected values with `path.join(...)`, `path.relative(...)`, or `FileSystemUtils.joinPath(...)`.
16- For human-readable output, either assert a deliberately normalized display format or normalize both actual and expected strings before comparing, for example with `FileSystemUtils.toPosixPath()` to convert backslashes to forward slashes for cross-platform consistency.
17- When touching path behavior, add coverage that would fail on Windows path separators.
18
19## Path Canonicalization
20
21Path identity is a recurring CI failure mode: Windows short/long paths, symlink or
22junction aliases, and case-insensitive file systems can spell the same existing
23directory differently.
24
25When asserting existing filesystem paths as identities, canonicalize both actual
26and expected paths first. Prefer `FileSystemUtils.canonicalizeExistingPath()` in
27project code and `fs.realpathSync.native()` in test-only expectations.
28
29Add an alias-path regression when touching path identity logic. If preserving
30user-typed path spelling is intentional, assert it separately from identity comparisons.
31
@@ −1 +1 @@
1−# Agent Guidance For `/work`
1+# OpenSpec Test Guidance
22
3−When working in this directory, use a product-facing lens first.
3+Applies to tests under `test/`.
44
5−Start from how the work is experienced by users, not from the internal command
6−or file structure. In this product there are two users:
5+## Running Tests
76
8−- Humans: they usually do OpenSpec work by prompting agents. They may run shell
9− commands for interactive setup or one-off actions, but prompts are the normal
10− interface.
11−- Agents: they need clear intent, discoverable state, unambiguous next actions,
12− and enough structured output to act safely.
7+- Focused file: `pnpm exec vitest run test/path/to/file.test.ts`
8+- Focused case: `pnpm exec vitest run test/path/to/file.test.ts -t "case name"`
9+- Full suite: `pnpm test`
10+- Run `pnpm run build` before focused CLI tests when implementation changes may leave `dist/` stale.
1311
14−Good human UX is usually good agent UX. A flow that is easy for a human to ask
15−for and understand is usually easier for an agent to execute, verify, and
16−explain.
12+## Cross-Platform Paths
1713
18−For roadmap or slice exploration:
14+- Do not hard-code Unix path separators in CLI output expectations unless the implementation intentionally emits POSIX paths.
15+- For filesystem paths, build expected values with `path.join(...)`, `path.relative(...)`, or `FileSystemUtils.joinPath(...)`.
16+- For human-readable output, either assert a deliberately normalized display format or normalize both actual and expected strings before comparing, for example with `FileSystemUtils.toPosixPath()` to convert backslashes to forward slashes for cross-platform consistency.
17+- When touching path behavior, add coverage that would fail on Windows path separators.
1918
20−- Describe the user-facing flow before the internal implementation.
21−- Ask what the human sees, asks for, approves, or corrects.
22−- Ask what the agent must discover, decide, execute, and report back.
23−- Ground reasoning in the current repo behavior before proposing new shape.
24−- Treat shell commands as supporting mechanics, not the primary product story.
25−- Prefer concrete workflows over abstract model language.
19+## Path Canonicalization
2620
27−When an answer gets confusing, reframe it as:
21+Path identity is a recurring CI failure mode: Windows short/long paths, symlink or
22+junction aliases, and case-insensitive file systems can spell the same existing
23+directory differently.
2824
29−```text
30−What does the human want?
31−What does the agent need to know?
32−Where does the work live?
33−What changes on disk?
34−How does the user know it worked?
35−```
25+When asserting existing filesystem paths as identities, canonicalize both actual
26+and expected paths first. Prefer `FileSystemUtils.canonicalizeExistingPath()` in
27+project code and `fs.realpathSync.native()` in test-only expectations.
28+
29+Add an alias-path regression when touching path identity logic. If preserving
30+user-typed path spelling is intentional, assert it separately from identity comparisons.
3631
