Skip to content

feat: Add settings-repo-ref tracking, harden write blocks, and expand developer guides #18

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
WilcoLouwerse wants to merge 4 commits into
base: feature/claude-code-tooling
Choose a base branch
from
Open

feat: Add settings-repo-ref tracking, harden write blocks, and expand developer guides #18

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5ffe18f
docs: update Claude developer guides and add repo config
WilcoLouwerse Apr 10, 2026
636dc21
docs: clarify L3/L5 detection criteria and update evals schema in wri…
WilcoLouwerse Apr 10, 2026
d919862
feat: add settings-repo-ref support, remove CLAUDE.local.md, bump to …
WilcoLouwerse Apr 13, 2026
6ae9e38
docs: update Claude developer guides and add repo config
WilcoLouwerse Apr 14, 2026
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
56 changes: 56 additions & 0 deletions .gitattributes
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# Auto detect text files and perform LF normalization
* text=auto

# Source code - always use LF
*.py text eol=lf
*.js text eol=lf
*.mjs text eol=lf

# Configuration files - always use LF
*.json text eol=lf
*.yml text eol=lf
*.yaml text eol=lf
*.toml text eol=lf
*.xml text eol=lf

# Styles - always use LF
*.css text eol=lf

# HTML and templates - always use LF
*.svg text eol=lf

# Documentation - always use LF
*.md text eol=lf
*.txt text eol=lf

# Shell scripts - always use LF
*.sh text eol=lf

# Dockerfiles - always use LF
Dockerfile text eol=lf
Dockerfile.* text eol=lf

# Git files - always use LF
.gitattributes text eol=lf
.gitignore text eol=lf
.gitmodules text eol=lf

# Windows script files - use CRLF
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf

# Binary files - do not modify
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.ico binary
*.webp binary
*.pdf binary
*.woff binary
*.woff2 binary
*.ttf binary
*.zip binary
*.gz binary
*.tar binary
2 changes: 2 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,2 +1,4 @@

.idea/
.claude/settings.json
.claude/settings.local.json
821 changes: 185 additions & 636 deletions docs/claude/README.md
View file
Open in desktop

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion docs/claude/app-lifecycle.md
View file
Open in desktop
Copy link
Copy Markdown
Member

@MWest2020 MWest2020 Apr 15, 2026

Choose a reason for hiding this comment

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

Voor de HWW 2.0 heb ik een json object die links bijhoudt, idee om dat hier ook te gaan doen? zodat we link maintenace op 1 plek krijgen. Ik zou denken dat we op en gegeven moment best ADR's weer los willen hebben omdat niet alleen hydra ze gebruikt?

Copy link
Copy Markdown
Contributor Author

@WilcoLouwerse WilcoLouwerse Apr 16, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Dat json object voor bijhouden van links klinkt goed, maar 2 vragen;

  1. Wat is het voordeel van dit json object die links bijhoudt? Een overzicht van alle links die er zijn, waar ze zijn en wat hun tekst en url is?
  2. Moet dit json object dan niet regelmatig worden geupdate/bijgehouden worden, kunnen we niet net zo goed regstreeks Claude AI gebruiken om de links zelf te vinden en updaten/bijhouden ipv via een extra.json bestand?

ADR's
My thoughs;

  1. Voor nu zijn alle 'company wide' ADR's hier in deze .github repo opgeslagen. NC Apps zouden ook app/project specifieke ADR's kunnen hebben als aanvulling hier op. (Zouden APP specifieke ADR's kunnen worden omgezet naar 'company wide' ADR's?)
  2. Ik zou zeggen dat we geen duplicatie van ADR's willen, 1 single source of truth, dus altijd naar Hydra verwijzen vanuit andere plekken.
  3. Uitzondering op punt 2 zou kunnen zijn dat een repo/project zo erg afwijkt dat er totaal andere ADR's nodig zijn, of andere ADR's als aanvulling op de 'company wide' ADR's.

Copy link
Copy Markdown
Contributor Author

@WilcoLouwerse WilcoLouwerse Apr 16, 2026

Choose a reason for hiding this comment

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

Hoe dan ook zijn beide punten goed om te bespreken, maar hier nu niet relevant voor het mergen van deze PR

Original file line number Diff line number Diff line change
Expand Up @@ -379,7 +379,7 @@ After completing the steps above, confirm:

App-specific ADRs live in `openspec/architecture/` and document why the app is built the way it is. They are created and explored during `/app-explore` sessions.

> **Company-wide ADRs** (ADR-001 through ADR-015) live in `apps-extra/.claude/openspec/architecture/` and apply to all Conduction apps. Only create an app-specific ADR when the decision is unique to that app.
> **Company-wide ADRs** (ADR-001 through ADR-015) live in `hydra/openspec/architecture/` and apply to all Conduction apps. Only create an app-specific ADR when the decision is unique to that app.

Good candidates for app-specific ADRs:
- Data storage approach (OpenRegister vs own tables)
Expand Down
Loading