Adding New Admin Modules

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• docs/PLAN.md
• CLAUDE.md
• .gitmodules
• package.json

Admin modules provide the core functionality for managing the Inkweave platform. These modules reside within the private inkweave-admin repository and interact with the public Inkweave application via a git submodule architecture. Adding a module involves extending the Next.js application structure, adhering to project-specific working rules, and ensuring proper integration with the upstream/inkweave codebase.

Sources: README.md:1-5, docs/PLAN.md

Module Architecture and Submodule Integration

The project uses a submodule-based architecture where the public inkweave repository is pinned to a specific commit. This allows the admin tools to reference internal logic or types from the main application without exposing administrative code publicly.

Dependency Management

When you add a new module that requires logic from the main app, you must reference files within the upstream/inkweave directory.

• Upstream Reference: The admin app pins the public repository at upstream/inkweave.
• Version Control: Submodule updates occur independently of the admin tool development.

The diagram shows the relationship between the admin repository, the pinned upstream submodule, and the deployment environment.
Sources: README.md:3-5, .gitmodules

Development Workflow

New modules follow a phased implementation approach defined in the project's planning documentation. You must consult the working rules before initiating a new module.

Core Development Steps

1. Phase Verification: Check docs/PLAN.md to identify the current development phase and ensuring the new module aligns with the roadmap.
2. Rule Compliance: Review CLAUDE.md for specific coding standards and interaction rules.
3. Submodule Alignment: Ensure the local upstream/inkweave directory is synchronized with the required commit from the main repository.

Component	Responsibility	Relevant File
Route Definitions	Defines the URL path and entry point	src/app/
Logic/Hooks	Handles state and admin-specific interactions	src/hooks/
Submodule Links	Interfaces with public app models	upstream/inkweave/

Sources: README.md:7-8, docs/PLAN.md, CLAUDE.md

Deployment and Security

All new modules automatically inherit the security configuration of the parent project. The application deploys to a Vercel project that requires a Vercel login for access.

Deployment Flow

If you push changes to the repository, Vercel triggers a build that includes the specified submodule state. The Vercel login serves as the primary gateway, preventing unauthorized access to the admin tools.

This sequence illustrates the path from code push to secure user access.
Sources: README.md:4-5, package.json

Implementation Summary

Adding an admin module requires creating the necessary Next.js routes within the repository while strictly referencing the upstream/inkweave submodule for shared logic. Developers must adhere to the status phases in the project plan and the guidelines in the specific working rules file to ensure consistency across the administrative suite.

Sources: README.md:7-8, docs/PLAN.md