Schema-Driven WordPress Plugin Completion

WordPress Plugin Development Team -- v1 Completion (PHP + React/TypeScript)

========================================
OVERVIEW
========================================

We are looking for an experienced DEVELOPMENT TEAM -- not a solo developer --
to complete a proprietary WordPress plugin currently ~55% complete. The
architecture, database schema, REST API structure, and requirements
documentation are all well-established. Your team's job is to complete
the implementation.

This is a SCHEMA-DRIVEN, FRAMEWORK-STYLE PROJECT. The heavy architectural
thinking is done. The work remaining is completing the framework components
and filling in the gaps where implementations are stubbed or partial.

Bids from solo developers will not be considered.

========================================
TECHNOLOGY STACK
========================================

- Backend: PHP 8.2+, WordPress 6.0+, custom REST API, Composer-managed
dependencies (MPDF, chillerlan/php-qrcode)
- Frontend: React 18+, TypeScript, Webpack, @wordpress/components, CKEditor 5
- Database: MySQL -- single physical table architecture with a logical
table abstraction layer
- Standards: WordPress Coding Standards (PHPCS enforced), TypeScript strict
mode, full multisite compliance

========================================
ARCHITECTURE HIGHLIGHTS
========================================

This is not a typical WordPress plugin. Understanding the architecture
is essential:

- SINGLE PHYSICAL TABLE, MULTIPLE LOGICAL ENTITIES. All entity types are
stored in one physical MySQL table via a Query Builder / Query Runner
abstraction layer. Adding a new entity type is a schema change, not a
schema + table change.

- SCHEMA-DRIVEN REST API. A PHP schema definition drives automatic endpoint
registration, field validation, and response shaping. REST handlers are
largely generic -- adding a new resource does not mean writing a new handler.

- SCHEMA-DRIVEN ADMIN UI. The frontend consumes a TypeScript schema module
(auto-generated from PHP at build time) to render list views, detail views,
forms, and actions. Renderers are generic, shared components -- not
per-resource code.

- SHARED COMPONENT ARCHITECTURE. Collection, group, table, and detail renderers
are written once and reused across all resources via schema configuration.

The gap between 55% and 100% is completing the framework itself (query runner
edge cases, renderer TODOs, permission middleware, pipeline integrations) --
not writing bespoke code for each resource.

========================================
WHAT IS ALREADY DONE
========================================

- Database schema (95%): physical table, logical table mapping,
Query Builder, Query Runner
- REST API routing and schema-driven dispatch (80%): all endpoints
registered, generic handlers partially implemented
- Admin UI framework (70%): schema-driven renderer architecture,
PHP -> TypeScript schema pipeline, webpack config, shared component
library scaffolded
- Third-party adapter architecture (40%): abstract base class,
WPForms adapter stubbed
- Plugin activation, deactivation, and multisite hooks (scaffolded)
- Full written requirements: separate backend and frontend developer
requirements documents with detailed specifications for every feature

========================================
WHAT NEEDS TO BE COMPLETED
========================================

BACKEND (PHP)
- Complete the generic REST handler layer (query runner relationship
handling, result transformation, permission middleware)
- Hierarchical RBAC permission system (6-level resolution) -- resolves
once, cached per request, consumed by all handlers
- WPForms adapter: event hook integration and stat aggregation
- Custom Field Definitions system: three-source CDF merging, key
uniqueness enforcement, utility endpoints
- Dashboard stats aggregation endpoint
- PDF generation pipeline: CKEditor 5 Twig templates + MPDF +
chillerlan/php-qrcode
- Settings admin page
- Multisite compliance: per-site DB migration with lazy version checks,
network admin panel
- Notes sub-entity support (generic, applies to all entity types
via schema flag)

FRONTEND (React/TypeScript)
- Complete shared renderer TODOs in collection, group, and table
components (the gap is in the framework, not per-resource)
- Dashboard stats view + system info panel
- Custom Fields UI: definition editor (shared component --
add/reorder/delete/validate, source badges, option set picker) and
value input fields (type-mapped inputs driven by field type in schema)
- Network admin panel: site overview table, per-site and bulk
migration actions
- CKEditor 5 integration in template editor
- Settings page UI
- QR code preview in detail view

========================================
TEAM COMPOSITION EXPECTED
========================================

We expect bids from TEAMS. Please include in your proposal:

- Number of backend developers and relevant experience (PHP 8.2+,
WordPress plugin development, REST APIs, RBAC systems, Twig templates + MPDF +
chillerlan/php-qrcode)
- Number of frontend developers and relevant experience (React 18+,
TypeScript, schema-driven UI, @wordpress/components, CKEditor 5 Twig templates)
- QA / testing resources
- Any additional team members you propose (project management,
DevOps, etc.)

Bids from solo developers will not be considered.

========================================
REQUIREMENTS FOR YOUR PROPOSAL
========================================

1. Describe your full team composition as outlined above
2. Provide examples of similar projects -- especially schema-driven
architectures, RBAC systems, or generic/shared admin UI frameworks
3. Describe your QA and testing approach
4. Propose a milestone-based delivery structure
5. Ask any clarifying technical questions -- detailed written requirements
documents will be shared with shortlisted teams for review and final
scope/price negotiation prior to award

========================================
NOTES
========================================

- Full requirements documentation is available to shortlisted teams
under NDA prior to award
- The existing codebase will be shared with winning team under NDA after the project is awarded
- WordPress Coding Standards compliance is required -- PHPCS is
configured and enforced
- TypeScript strict mode is required -- no "any" types
- All queries to the plugin's physical table must go through the
Query Builder / Query Runner -- no direct $wpdb calls against that table
- All other $wpdb queries must use $wpdb->prepare()

========================================
IMPORTANT -- PLEASE READ
========================================

To confirm that your bid -- both amount and timeline -- is a genuine
estimate based on the full scope of work described in this posting and
not a placeholder bid, please include the phrase SOLI DEO GLORIA at the
beginning of your proposal. Bids without this phrase will be declined
without response.