Skip to content

Commit 76dfad0

Browse files
itsflaiddevmap-agent
itsflaid
and
devmap-agent
committed
Remove devmap ask command and all related references
- Delete src/commands/ask.ts and test/ask-command.test.ts - Clean index.ts, provider.ts, groq.ts, prompts.ts, doctor.ts, featureDetector.ts - Update all test files to remove/adapt ask references - Remove devmap ask from all documentation (.md files) - Update personal development notes (PROGRESS, TEST, DEBUG) - 112 tests pass, typecheck lulus, CLI help bersih Co-authored-by: devmap-agent <238585242+devmap-agent@users.noreply.github.com>
1 parent 9d23cf4 commit 76dfad0

26 files changed

Lines changed: 299 additions & 1393 deletions

‎AGENTS.md‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,6 @@
33
When working in this repository:
44

55
- Create a branch before making changes unless the user explicitly asks to work on the current branch.
6-
- Use branch names with the `codex/` prefix, for example `codex/fix-analyzer`.
76
- Keep changes scoped to the user request.
87
- Do not revert unrelated user changes.
98
- Prefer opening a pull request instead of pushing directly to `main`, unless the user explicitly asks to push to `main`.

‎CONTRIBUTING.md‎

Lines changed: 193 additions & 195 deletions
Original file line numberDiff line numberDiff line change
@@ -1,197 +1,195 @@
1-
# Contributing to DevMap
2-
3-
Thanks for your interest in contributing. This document covers everything
4-
you need to get started.
5-
6-
---
7-
8-
## Project Structure
9-
10-
```
11-
devmap/
12-
├── apps/
13-
│ └── web/ ← landing page (post-MVP, not active yet)
14-
├── packages/
15-
│ └── cli/ ← core CLI — this is where you'll work
16-
│ ├── src/
17-
│ │ ├── commands/ ← one file per CLI command
18-
│ │ ├── analyzers/ ← static analysis logic
19-
│ │ ├── ai/ ← AI provider abstraction
20-
│ │ ├── cache/ ← file hashing + snapshot
21-
│ │ └── utils/ ← output, config, helpers
22-
│ └── test/
23-
│ └── fixtures/ ← dummy projects for testing
24-
├── docs/ ← PRD, architecture, commands, roadmap
25-
└── README.md
26-
```
27-
28-
Most contributions will be inside `packages/cli/src/`.
29-
30-
---
31-
32-
## Setup
33-
34-
**Requirements:** Node.js 18+, pnpm
35-
36-
```bash
37-
# Clone the repo
1+
# Contributing to DevMap
2+
3+
Thanks for your interest in contributing. This document covers everything
4+
you need to get started.
5+
6+
---
7+
8+
## Project Structure
9+
10+
```
11+
devmap/
12+
├── apps/
13+
│ └── web/ ← landing page (post-MVP, not active yet)
14+
├── packages/
15+
│ └── cli/ ← core CLI — this is where you'll work
16+
│ ├── src/
17+
│ │ ├── commands/ ← one file per CLI command
18+
│ │ ├── analyzers/ ← static analysis logic
19+
│ │ ├── ai/ ← AI provider abstraction
20+
│ │ ├── cache/ ← file hashing + snapshot
21+
│ │ └── utils/ ← output, config, helpers
22+
│ └── test/
23+
│ └── fixtures/ ← dummy projects for testing
24+
├── docs/ ← PRD, architecture, commands, roadmap
25+
└── README.md
26+
```
27+
28+
Most contributions will be inside `packages/cli/src/`.
29+
30+
---
31+
32+
## Setup
33+
34+
**Requirements:** Node.js 18+, pnpm
35+
36+
```bash
37+
# Clone the repo
3838
git clone https://github.com/itsflaid/devmap
39-
cd devmap
40-
41-
# Install dependencies
42-
pnpm install
43-
44-
# Link CLI globally so you can test it like a real user
45-
cd packages/cli
46-
npm link
47-
48-
# Verify it works
49-
devmap --version
50-
```
51-
52-
---
53-
54-
## Development Workflow
55-
56-
```bash
57-
# Run CLI in development (no build needed)
58-
cd packages/cli
59-
pnpm dev
60-
61-
# Or run a specific command directly
62-
npx tsx src/index.ts analyze
63-
npx tsx src/index.ts ask "how does auth work"
64-
65-
# Build for production
66-
pnpm build
67-
68-
# Run tests
69-
pnpm test
70-
```
71-
72-
---
73-
74-
## Testing Your Changes
75-
76-
Always test against real projects, not just the fixtures.
77-
78-
```bash
79-
# Go to any real project on your machine
80-
cd ~/projects/some-nextjs-app
81-
82-
# Run devmap against it
83-
devmap analyze
84-
devmap ask "how does auth work"
85-
devmap doctor
86-
```
87-
88-
The fixture projects in `test/fixtures/` are for automated tests.
89-
Manual testing against real projects catches things fixtures miss.
90-
91-
**Before submitting a PR, test against at least:**
92-
- A Next.js project
93-
- An Express project
94-
- A project with many files (100+)
95-
96-
---
97-
98-
## Adding a New Command
99-
100-
1. Create `packages/cli/src/commands/yourcommand.ts`
101-
2. Implement the command logic
102-
3. Register it in `packages/cli/src/index.ts`
103-
4. Add documentation to `docs/COMMANDS.md`
104-
5. Add test fixtures if needed
105-
106-
Follow the pattern of existing commands — use `output.ts` utilities
107-
for all terminal output, never `console.log` directly.
108-
109-
---
110-
111-
## Adding a New AI Provider
112-
113-
1. Create `packages/cli/src/ai/yourprovider.ts`
114-
2. Implement the provider interface:
115-
116-
```ts
117-
export async function complete(options: CompleteOptions): Promise<string>
118-
export async function isAvailable(): Promise<boolean>
119-
export function getModels(): string[]
120-
```
121-
122-
3. Register the provider in `packages/cli/src/ai/provider.ts`
123-
4. Add the provider to `devmap init` options in `packages/cli/src/commands/init.ts`
124-
5. Update the provider table in `README.md`
125-
126-
---
127-
128-
## Adding Framework Support
129-
130-
Framework detection lives in `packages/cli/src/analyzers/frameworkDetector.ts`.
131-
132-
Each framework needs:
133-
- Detection logic (from `package.json` + file patterns)
134-
- Entry point patterns specific to that framework
135-
- Test fixture in `test/fixtures/`
136-
137-
Before adding a new framework, open an issue first to discuss.
138-
Framework support affects output quality significantly —
139-
better to do one framework well than many frameworks poorly.
140-
141-
---
142-
143-
## Code Style
144-
145-
- TypeScript strict mode is enabled — no `any` without a comment explaining why
146-
- Use `output.ts` utilities for all terminal output
147-
- Keep command files thin — business logic belongs in `analyzers/` or `ai/`
148-
- Prompts belong in `ai/prompts.ts`, never inline in command files
149-
- One responsibility per file
150-
151-
---
152-
153-
## Pull Request Guidelines
154-
155-
**Small PRs are easier to review.** If you're adding a big feature,
156-
open an issue first to discuss the approach before writing code.
157-
158-
PR checklist:
159-
- [ ] Tested against a real Next.js project
160-
- [ ] Tested against a real Express project
161-
- [ ] No raw `console.log` in command files
162-
- [ ] New commands documented in `docs/COMMANDS.md`
163-
- [ ] `devmap doctor` still passes after your changes
164-
165-
---
166-
167-
## Reporting Bugs
168-
169-
Run `devmap doctor` first and include the output in your bug report.
170-
This gives all the context needed to reproduce the issue.
171-
172-
Open an issue with:
173-
1. `devmap doctor` output
174-
2. What command you ran
175-
3. What you expected to happen
176-
4. What actually happened
177-
178-
---
179-
180-
## Roadmap & Feature Requests
181-
182-
Check `docs/ROADMAP.md` before requesting a feature —
183-
it might already be planned.
184-
185-
For features not in the roadmap, open an issue with:
186-
- The problem you're trying to solve
187-
- Why existing commands don't solve it
188-
- What the command/output would look like
189-
190-
Features that solve real problems with clear use cases
191-
get prioritized over features that are technically interesting.
192-
193-
---
194-
195-
## License
196-
39+
cd devmap
40+
41+
# Install dependencies
42+
pnpm install
43+
44+
# Link CLI globally so you can test it like a real user
45+
cd packages/cli
46+
npm link
47+
48+
# Verify it works
49+
devmap --version
50+
```
51+
52+
---
53+
54+
## Development Workflow
55+
56+
```bash
57+
# Run CLI in development (no build needed)
58+
cd packages/cli
59+
pnpm dev
60+
61+
# Or run a specific command directly
62+
npx tsx src/index.ts analyze
63+
64+
# Build for production
65+
pnpm build
66+
67+
# Run tests
68+
pnpm test
69+
```
70+
71+
---
72+
73+
## Testing Your Changes
74+
75+
Always test against real projects, not just the fixtures.
76+
77+
```bash
78+
# Go to any real project on your machine
79+
cd ~/projects/some-nextjs-app
80+
81+
# Run devmap against it
82+
devmap analyze
83+
devmap doctor
84+
```
85+
86+
The fixture projects in `test/fixtures/` are for automated tests.
87+
Manual testing against real projects catches things fixtures miss.
88+
89+
**Before submitting a PR, test against at least:**
90+
- A Next.js project
91+
- An Express project
92+
- A project with many files (100+)
93+
94+
---
95+
96+
## Adding a New Command
97+
98+
1. Create `packages/cli/src/commands/yourcommand.ts`
99+
2. Implement the command logic
100+
3. Register it in `packages/cli/src/index.ts`
101+
4. Add documentation to `docs/COMMANDS.md`
102+
5. Add test fixtures if needed
103+
104+
Follow the pattern of existing commands — use `output.ts` utilities
105+
for all terminal output, never `console.log` directly.
106+
107+
---
108+
109+
## Adding a New AI Provider
110+
111+
1. Create `packages/cli/src/ai/yourprovider.ts`
112+
2. Implement the provider interface:
113+
114+
```ts
115+
export async function complete(options: CompleteOptions): Promise<string>
116+
export async function isAvailable(): Promise<boolean>
117+
export function getModels(): string[]
118+
```
119+
120+
3. Register the provider in `packages/cli/src/ai/provider.ts`
121+
4. Add the provider to `devmap init` options in `packages/cli/src/commands/init.ts`
122+
5. Update the provider table in `README.md`
123+
124+
---
125+
126+
## Adding Framework Support
127+
128+
Framework detection lives in `packages/cli/src/analyzers/frameworkDetector.ts`.
129+
130+
Each framework needs:
131+
- Detection logic (from `package.json` + file patterns)
132+
- Entry point patterns specific to that framework
133+
- Test fixture in `test/fixtures/`
134+
135+
Before adding a new framework, open an issue first to discuss.
136+
Framework support affects output quality significantly —
137+
better to do one framework well than many frameworks poorly.
138+
139+
---
140+
141+
## Code Style
142+
143+
- TypeScript strict mode is enabled — no `any` without a comment explaining why
144+
- Use `output.ts` utilities for all terminal output
145+
- Keep command files thin — business logic belongs in `analyzers/` or `ai/`
146+
- Prompts belong in `ai/prompts.ts`, never inline in command files
147+
- One responsibility per file
148+
149+
---
150+
151+
## Pull Request Guidelines
152+
153+
**Small PRs are easier to review.** If you're adding a big feature,
154+
open an issue first to discuss the approach before writing code.
155+
156+
PR checklist:
157+
- [ ] Tested against a real Next.js project
158+
- [ ] Tested against a real Express project
159+
- [ ] No raw `console.log` in command files
160+
- [ ] New commands documented in `docs/COMMANDS.md`
161+
- [ ] `devmap doctor` still passes after your changes
162+
163+
---
164+
165+
## Reporting Bugs
166+
167+
Run `devmap doctor` first and include the output in your bug report.
168+
This gives all the context needed to reproduce the issue.
169+
170+
Open an issue with:
171+
1. `devmap doctor` output
172+
2. What command you ran
173+
3. What you expected to happen
174+
4. What actually happened
175+
176+
---
177+
178+
## Roadmap & Feature Requests
179+
180+
Check `docs/ROADMAP.md` before requesting a feature —
181+
it might already be planned.
182+
183+
For features not in the roadmap, open an issue with:
184+
- The problem you're trying to solve
185+
- Why existing commands don't solve it
186+
- What the command/output would look like
187+
188+
Features that solve real problems with clear use cases
189+
get prioritized over features that are technically interesting.
190+
191+
---
192+
193+
## License
194+
197195
By contributing, you agree your contributions will be licensed under MIT.

0 commit comments

Comments
 (0)