Skip to content

CLAUDE.md

Latest commit

 

History

History
44 lines (29 loc) · 2.64 KB

CLAUDE.md

File metadata and controls

44 lines (29 loc) · 2.64 KB
Raw

About

Frappe Wiki (Version 3), is a modern Wiki product built on Frappe Framework and Frappe UI (VueJS).

IMPORTANT

Always load and user frappe-app-dev skills.

Development Details

Unless mentioned, the site is wiki.localhost with Administrator/admin credentials.

Planning / Spec-ing

Use Tracer bullets comes from the Pragmatic Programmer. When building systems, you want to write code that gets you feedback as quickly as possible. Tracer bullets are small slices of functionality that go through all layers of the system, allowing you to test and validate your approach early. This helps in identifying potential issues and ensures that the overall architecture is sound before investing significant time in development.

Implementation Guidelines

  • Create a new branch before working on a new feature/spec (branch name patterns: feat/, fix/, just like conventional commit pre-fixes)
  • Reconcile the spec and log the progress after each phase of development
  • Commit after each meaningful phase
  • Commit the spec before the development commits
  • Use comments only when necessary to explain "why?" not "how?", how must be clear from the code itself

Frontend / Backend Sync

  • Whenever a new field is added to a backend DocType that is surfaced in the frontend (e.g. settings panels), it must also be handled in the corresponding frontend component so the two stay in sync. This is a convention/reminder only — there is no automatic syncing mechanism; the frontend enumerates fields explicitly.

Regression tests

  • When we fix a bug, add at the very least a Unit test, and verify before/after by temp revert of fix to make sure the test tests what is intended
  • For bigger features/workflows, e2e playwright tests are a must.

Pull Requests

  • The canonical repo is frappe/wiki (git remote upstream). Ignore the fork (origin) entirely.
    • Branch off upstream/develop (run git fetch upstream develop first), not local/fork develop — the fork's develop is often stale and inflates the diff.
    • Push the feature branch to upstream (frappe/wiki) and raise the PR there: gh pr create --repo frappe/wiki --base develop .... Set gh repo set-default frappe/wiki so this is the default.
    • Before raising, sanity-check the diff is only your files: git diff --stat upstream/develop..<branch>. A huge diff means you based on or targeted the wrong (fork) develop — fix the base before opening the PR.
  • Raise PR always against the develop branch
  • Keep pull request descriptions stupid simple
  • Some formats:
    1. h2 Problem (1-2 sentences), h2 Solution: good for bugs, etc.
    2. h2 Why? h2 What? h2 How?: good for new features and enhancements