stage2-2 and docs

This commit is contained in:
alorig
2025-11-19 21:19:53 +05:00
parent 72e1f25bc7
commit 52c9c9f3d5
14 changed files with 1259 additions and 347 deletions

View File

@@ -0,0 +1,89 @@
# Stage 2 Planner & Wizard UX
## Overview
- Feature flag: `USE_SITE_BUILDER_REFACTOR` (must be `true`)
- Goal: ship state-aware, guided Site Builder experience and expose cluster/taxonomy readiness to Planner UI
- Dependencies: Stage 1 migrations/services already deployed
- Entry point: `/sites/builder/workflow/:blueprintId` (protected route)
---
## Backend Enhancements
### New services / endpoints
| Component | Description | File |
| --- | --- | --- |
| `WizardContextService` | Aggregates workflow state, cluster stats, taxonomy summaries, coverage counts | `backend/igny8_core/business/site_building/services/wizard_context_service.py` |
| Workflow context API | `GET /api/v1/site-builder/siteblueprint/{id}/workflow/context/` returns `workflow`, `cluster_summary`, `taxonomy_summary`, `coverage`, `next_actions` | `modules/site_builder/views.py` |
| Workflow serializer helpers | `SiteBlueprintSerializer` now returns `workflow_state` + `gating_messages` via `WorkflowStateService.serialize_state()` | `modules/site_builder/serializers.py` |
### Workflow telemetry & logging
- `WorkflowStateService` normalizes step metadata (`status`, `code`, `message`, `updated_at`)
- Emits structured log events (`wizard_step_updated`, `wizard_blocking_issue`) for future analytics
- `serialize_state()` provides consistent payload for API, wizard store, and planner warnings
---
## Frontend Implementation
### API layer
- Added interfaces + calls (`fetchSiteBlueprints`, `fetchSiteBlueprintById`, `updateSiteBlueprint`, `fetchWizardContext`, `updateWorkflowStep`)
- Located in `frontend/src/services/api.ts`
### Zustand store
| Store | Purpose |
| --- | --- |
| `useBuilderWorkflowStore` | Tracks `blueprintId`, `currentStep`, `completedSteps`, `blockingIssues`, `workflowState`, `context`, telemetry queue |
- Actions: `initialize`, `refreshState`, `goToStep`, `completeStep`, `setBlockingIssue`, `clearBlockingIssue`, `flushTelemetry`, `reset`
- Persists last blueprint + step in `builder-workflow-storage` (sessionStorage)
### Wizard shell & routing
- New page: `WorkflowWizard` at `/sites/builder/workflow/:blueprintId`
- Lazy-loaded via `App.tsx`
- Refreshes context every 10s to keep telemetry/current state accurate
- Progress indicator (`WizardProgress`) shows completed/current/blocked steps
### Step components
| Step | Component | Status |
| --- | --- | --- |
| 1 Business Details | `steps/BusinessDetailsStep.tsx` | **Functional** (saves blueprint + completes step) |
| 2 Cluster Assignment | `steps/ClusterAssignmentStep.tsx` | Placeholder UI (shows stats, next iteration: attach/detach clusters) |
| 3 Taxonomy Builder | `steps/TaxonomyBuilderStep.tsx` | Placeholder UI (future: taxonomy tree/table + imports) |
| 4 AI Sitemap Review | `steps/SitemapReviewStep.tsx` | Placeholder UI (future: grid w/ grouping + regenerate) |
| 5 Coverage Validation | `steps/CoverageValidationStep.tsx` | Placeholder UI (future: coverage cards + gating logic) |
| 6 Ideas Hand-off | `steps/IdeasHandoffStep.tsx` | Placeholder UI (future: page selection + prompt override) |
### Planner UX TODOs (next iteration)
- Cluster matrix view linking back into wizard
- Taxonomy management table with inline edits & imports
- Planner dashboard banner if blueprint missing requirements
---
## Testing & Verification
1. Set `USE_SITE_BUILDER_REFACTOR=true`
2. Create or reuse a `SiteBlueprint` and open `/sites/builder/workflow/{id}`
3. Confirm payload from `GET /workflow/context/` includes:
- `workflow.steps` array with `status`, `code`, `message`
- `cluster_summary` (counts + list)
- `taxonomy_summary`
- `coverage` (pages, statuses)
- `next_actions`
4. Step 1 (Business Details) should allow update/save → triggers workflow state update
5. Steps 26 currently show placeholders + gating alerts (will be wired to new UIs)
Automated tests pending: once UI solidified, add Cypress flows for each step + Zustand store unit tests.
---
## Open Items / Future Work
- Build full step experiences (tables, drag/drop mapping, AI sitemap review UI)
- Planner cluster matrix & taxonomy management views
- Telemetry dispatcher (currently logs to console)
- Accessibility polish: keyboard navigation, helper tooltips, context drawer
- QA automation + e2e coverage
---
*Last updated: 2025-11-19*

View File

@@ -0,0 +1,85 @@
# Stage 3 Writer / Linker / Optimizer Enhancements
## Objective
Propagate the new metadata (clusters, taxonomies, entity types, attributes) through the planner → writer pipeline, enforce validation before publish, and unlock linker/optimizer capabilities. Stage 3 builds directly on Stage 2s wizard outputs; all changes stay behind `USE_SITE_BUILDER_REFACTOR` until pilot-ready.
---
## Backend Plan
### 1. Metadata Audit & Backfill
| Task | Description | Owner |
| --- | --- | --- |
| Backfill tables | Implement data migration using the stub added in `writer/migrations/0012_metadata_mapping_tables.py` to populate `ContentClusterMap`, `ContentTaxonomyMap`, `ContentAttributeMap` for legacy content/tasks. | Backend lead |
| Entity defaults | Ensure existing Tasks/Content have sensible defaults for `entity_type`, `taxonomy_id`, `cluster_role` (e.g., `blog_post` + `supporting`). | Backend lead |
| Audit script | Management command `python manage.py audit_site_metadata --site {id}` summarizing gaps per site. | Backend lead |
### 2. Pipeline Updates
| Stage | Changes |
| --- | --- |
| Ideas → Tasks | Update Task creation so every task inherits cluster/taxonomy/attribute metadata. Enforce “no cluster, no idea/task” rule. |
| Tasks → Content | Adjust `PageGenerationService` / writer Celery tasks to persist mappings into `ContentClusterMap`, `ContentTaxonomyMap`, `ContentAttributeMap`. |
| AI Prompts | Update prompts to include cluster role, taxonomy context, product attributes. Leverage Stage 1 metadata fields like `dimension_meta`, `attribute_values`. |
| Validation services | Add reusable validators (e.g., `ensure_required_attributes(task)`), returning structured errors for UI. |
### 3. Linker & Optimizer
| Component | Requirements |
| --- | --- |
| LinkerService | Use mapping tables to suggest hub ↔ supporting ↔ attribute links; include priority score + context snippet. |
| OptimizerService | Scorecards factoring cluster coverage, taxonomy alignment, attribute completeness. Provide `/sites/{id}/progress` and `/writer/content/{id}/validation` endpoints. |
| Caching/Indexes | Add DB indexes for frequent join patterns (content ↔ cluster_map, taxonomy_map). |
### 4. API Additions
- `GET /api/v1/sites/{id}/progress/` → cluster-level completion + validation flags.
- `GET /api/v1/writer/content/{id}/validation/` → aggregated checklist for Writer UI.
- `POST /api/v1/writer/content/{id}/validate/` → re-run validators and return actionable errors.
---
## Frontend Plan
### 1. Planner / Ideas / Writer Enhancements
| Area | UX Changes |
| --- | --- |
| Planner Ideas & Writer Tasks lists | Show chips/columns for cluster, taxonomy, entity type, validation status; add filters. |
| Writer Editor | Sidebar module summarizing cluster, taxonomy tree, attribute form; validation panel blocking publish until cleared. |
| Linker UI | Group internal link suggestions by cluster role; show context snippet + CTA to insert link. |
| Optimizer Dashboard | Scorecards per cluster dimension with color coding + “next action” cards. |
| Site Progress Widgets | On site overview, show completion bars (hub/supporting/attribute); deep link to problematic clusters/pages. |
### 2. Validation & Notifications
- Inline toasts + optional email when validation fails.
- Publish button disabled until validators pass; display error list linking to relevant fields.
- Credit reminder banner when user regenerates content/optimization tasks.
---
## Testing Strategy
| Area | Automated | Manual |
| --- | --- | --- |
| Pipeline | Unit tests for Task → Content metadata persistence, Prompt builders. | End-to-end: blueprint → ideas → tasks → content. |
| Validation | Tests ensuring validators trigger correct errors. | Attempt publish without taxonomy/attributes; confirm UX flow. |
| Linker/Optimizer | Service tests for scoring & suggestions. | Performance profiling on large datasets; UX review. |
| Progress Widgets | Component tests verifying counts. | Compare UI vs. database for pilot site. |
---
## Rollout Checklist
1. Deploy Stage 3 backend with feature flag ON in staging.
2. Run metadata backfill; verify progress dashboards and validators.
3. QA regression: planner → writer flow, linker, optimizer.
4. Pilot with internal content team; gather feedback on validation friction.
5. Optimize slow queries (indexes/caching) before production rollout.
6. Update training docs/videos for writers; enable flag gradually across accounts.
---
## Open Questions / Risks
- Volume impact when backfilling large content sets? (Plan: chunked migrations + progress logs)
- Telemetry volume for validator events? (Plan: aggregate counts; sample per site)
- WordPress deploy parity: ensure metadata travels through sync (handled in Stage 4).
---
*Last updated: 2025-11-19*

View File

@@ -0,0 +1,89 @@
# Stage 4 Publishing & Sync Integration
## Objective
Achieve feature parity between IGNY8-hosted deployments and WordPress sites using the shared metadata model introduced in Stages 13. This includes two-way sync for taxonomies/products, deployment readiness checks, and operational tooling.
---
## Backend Plan
### 1. Sync Architecture
| Task | Description |
| --- | --- |
| Audit adapters | Review current WordPress adapter + sync service; confirm endpoints for categories, tags, WooCommerce attributes/products. |
| Data mapping | Document mapping between WordPress taxonomies and IGNY8 `SiteBlueprintTaxonomy`, `ContentTaxonomyMap`, `external_reference` fields. |
| Sync configs | Extend integration settings to store WordPress/Woo credentials, sync frequency, and site archetype. |
### 2. Enhancements
| Area | Implementation |
| --- | --- |
| Import | `ContentSyncService` fetches WP taxonomies/products/custom post types -> maps to IGNY8 schema via `TaxonomyService`. Auto-create missing clusters/taxonomies with an `imported` flag. |
| Export | `WordPressAdapter` ensures taxonomies exist before publishing posts/products. Pushes product attributes/tags ahead of content. |
| Sync Health APIs | `/sites/{id}/sync/status`, `/sites/{id}/sync/run`, returning last sync time, mismatch counts, error logs. |
| Deployment | `SitesRendererAdapter` consumes cluster/taxonomy metadata for navigation, breadcrumbs, internal links. Deployment readiness check ensures cluster coverage, content status, validation flags. |
| Logging & Monitoring | Structured logs per sync run (duration, items processed, failures). Alerts for repeated sync failures or deployment errors. |
---
## Frontend Plan
### 1. Sync Dashboard
| Component | Features |
| --- | --- |
| Parity indicators | Status icons for taxonomies, products, posts. |
| Controls | Manual sync, retry failed items, view logs (with pagination/filtering). |
| Detail drawer | Shows mismatched items, suggested fixes, quick links into Planner/Writer. |
### 2. Deployment Panel
| Component | Features |
| --- | --- |
| Readiness checklist | Displays cluster coverage, content validation, sync status. |
| Actions | Deploy and rollback buttons with confirmation modals and logging. |
| Notifications | Toasts for success/failure; optional email/webhook integration. |
### 3. WordPress Connection UI
| Task | Description |
| --- | --- |
| Integration status | Show credential health, last sync time, active site type. |
| Troubleshooting | Inline helper text + links to docs/runbook. |
---
## Operational Runbooks
- Sync troubleshooting steps (auth errors, taxonomy mismatches, WooCommerce throttling).
- Rollback procedures for failed deployments.
- Escalation path + scripts to force sync, clear queue, or recover failed deploy.
---
## Testing Strategy
| Area | Automated | Manual |
| --- | --- | --- |
| Sync logic | Integration tests hitting mocked WP APIs, verifying mapping + retries. | Staging sync from live WP instance; verify taxonomy parity. |
| Deployment | Renderer tests using fixture metadata to ensure navigation/internal links. | Deploy IGNY8 site; inspect front-end output, breadcrumbs, menus. |
| Dashboards | Component/unit tests for Sync/Deployment panels. | Pilot user testing + UX review. |
| Runbooks | N/A | Tabletop exercises for failure scenarios (sync fails, deploy rollback). |
---
## Rollout Checklist
1. Enable Stage 4 flag in staging; run full import/export tests.
2. Pilot with one IGNY8-hosted and one WordPress-hosted site.
3. Train support on dashboards/runbooks; ensure alerting configured.
4. Announce availability; roll out gradually to accounts with WordPress integrations.
5. Monitor logs/alerts during first production syncs; iterate on tooling as needed.
---
## Risks & Mitigations
| Risk | Mitigation |
| --- | --- |
| API rate limits (WordPress/WooCommerce) | Backoff + batching, highlight in dashboard. |
| Data mismatches (taxonomies/products) | Detailed diff view + retry actions + runbook. |
| Deployment failures | Preflight checks + rollback buttons + structured logs. |
| Operational overhead | Alerting dashboards + documented on-call runbook. |
---
*Last updated: 2025-11-19*