Skip to main content

Knowledge > Runbooks > Agent Ops > How to Use and Maintain the Feature Registry

How to Use and Maintain the Feature Registry

The feature registry is a soft gate that prevents agents from building features in the wrong codebase, duplicating work, or extending unapproved features. Check it before building anything new.

The File​

C:\dev\FEATURE_REGISTRY.md — 209+ features across all 5 properties. Organized by property.

Before Building a New Feature: The Decision Tree​

Is the feature in FEATURE_REGISTRY.md?
├── NO  → Warn the founder. Explain where you plan to build it. Wait for approval.
├── YES, under a DIFFERENT property → STOP. Ask the founder. Do NOT proceed.
├── YES, marked `unapproved` → Do NOT build it. Surface to founder if it seems urgent.
└── YES, marked `approved` or `complete` → Proceed. Update the registry when done.

Step-by-Step​

1. Search the Registry for Your Feature​

Open C:\dev\FEATURE_REGISTRY.md and search for the feature name or related keywords.

Also search for related features — sometimes a feature is listed under a slightly different name or as part of a broader feature group.

2. Determine the Feature Status​

Each entry has a status:

StatusMeaningAction
approvedFounder has approved this feature to be builtBuild it
completeAlready built and deployedDon't rebuild — check if update/fix is needed
unapprovedHas been discussed but not approved for developmentDo NOT build
Not listedNot in the registry at allWarn founder, get approval first

3. If the Feature Is Not Listed: Warn and Propose​

Send a message to the founder:

"The feature '[feature name]' is not in the Feature Registry. I plan to build it in [codebase] under [area]. This makes sense because [reason]. Should I proceed?"

Wait for a response before building. The registry exists to prevent scope creep and cross-property confusion.

4. If the Feature Is Under the Wrong Property: Stop​

If the registry lists a feature under pewsearch/ but you're about to build it in churchwiseai-web/, STOP. This is not a minor naming issue — it means there's a property ownership conflict that only the founder can resolve.

Example: AI features (chatbot analytics, voice call history) MUST be in churchwiseai-web/ — never in pewsearch/.

5. When You Build an Approved Feature: Update the Registry​

When a feature moves from approved → complete, update the registry entry in the same PR as the feature code:

  1. Find the feature entry in FEATURE_REGISTRY.md
  2. Update status from approved to complete
  3. Add the completion date and the relevant code file path (optional but helpful)
  4. Commit this change alongside the feature code
git add C:/dev/FEATURE_REGISTRY.md
git add src/app/api/new-feature/route.ts
git commit -m "feat: [feature name] — mark complete in registry"

6. When Adding a Brand-New Approved Feature to the Registry​

If the founder approves a new feature that isn't in the registry, add it:

## ChurchWiseAI

| Feature | Status | Description |
|---------|--------|-------------|
| New Feature Name | approved | Brief description of what this does and why |

Fill in:

  • Feature: Short, clear name
  • Property: Which codebase owns it
  • Status: approved (not complete until built)
  • Description: One sentence — what it does and the business reason

7. Registry Integrity Rules​

  • One entry per feature — no duplicates across properties
  • AI features belong to churchwiseai-web/ — never pewsearch, never ITW
  • Directory features belong to pewsearch/web/ — never churchwiseai-web
  • The registry is the source of truth for what is and isn't approved

Verification​

  • FEATURE_REGISTRY.md correctly reflects the feature's status after your work
  • No feature is built in the wrong property
  • The registry update is committed in the same PR as the feature code

See Also​