Ligora.ai — Consolidated Master Product Blueprint v1.1

Дата: 10 ноября 2026
Статус: CONSOLIDATION CANDIDATE — не окончательно утверждённый Blueprint
Этап: Product strategy, architecture, interactive experience concept
Последовательность: сначала интерактивный сайт, затем Blueprint Completeness & Consistency Review, потом UX Wireframes и отдельное разрешение на разработку SaaS.
Документ не подтверждает product-market fit, не санкционирует production-разработку и не доказывает реализованную безопасность.

1. Executive Vision

Ligora.ai — проектируемая SEO Strategy Execution & Intelligence Platform для собственных SEO-команд, affiliate SEO operators, in-house SEO departments и SEO/marketing agencies. Она связывает проекты, стратегии (необязательные), целевые страницы, запросы, планы ссылок, доноров, предложения, подрядчиков, заказы, контент, фактические ссылки, расходы и поисковую результативность.

Исходная идея: Project → Strategy? → Target Page → Keywords → Link Plan → Execution → Placement → Financials / Performance. Ключевой принцип: Meaning emerges from connections. Обязательное UX-требование: минимум ручной работы, batch-first, spreadsheet-first, исключения вместо обязательной смены статусов.

Продукт не проектируется как marketplace ссылок, универсальный таск-менеджер, собственный комплексный rank tracker или система с обязательными кабинетами внешних vendors.

2. История концепции и независимое исследование

Первоначальная гипотеза — Strategy Execution Platform for Link-Building Teams.
Gemini Stage 01–06: JTBD/evidence; Buy vs Build и TCO; конкуренты и defensibility; TAM/SAM/SOM и тарифы; product/MVP/COGS; безопасность и право. Gemini Stage 07–09 в исходном корпусе не завершены.
Независимое Claude review (CLAUDE_00–CLAUDE_10) выявило ошибки в тарифах конкурентов, стоимости API, TCO, расчётах рынка, архитектуре tenant isolation и гарантии статусов backlinks.
Claude рекомендовал условный NARROW procurement-memory и коммерческую валидацию до сборки. Это мнение исследователя, не утверждённое решение основателя.
Последующие решения основателя привели к более широкой архитектуре для SEO departments с гибкими организационными моделями, стратегиями, закупками, финансами и multi-level link registry. Расширение scope не опровергает коммерческие риски узкого продукта.

2.1. Рыночная модель — только история гипотез

В исторической Gemini Stage 04 модели: TAM 63,550 организаций; qualified ICP 9,961; SAM 7,192; SAM ARR $50M; Y3 customers 210. Это UNVALIDATED MODEL OUTPUTS, а не факты. В независимом Claude review фактический SAM назван неизвестным, сценарные 1–12 тыс. организаций не являются верифицированным измерением. Не использовать эти значения как доказанный рынок, прогноз выручки или инвестиционный тезис.

2.2. Конкурентные категории и substitutes

Категория	Примеры	Что нельзя утверждать без проверки
Outreach & link CRM	Pitchbox, BuzzStream	Что у них отсутствуют закупки, история или внутренние функции, не описанные публично
Backlink management & reporting	BacklinkManager.io, BacklinkCRM.io	Что Ligora первая с отчётами, CRM или ссылочной историей
Backlink monitoring	LinkChecker.pro, Linkody	Что автоматическая проверка ссылок уникальна
Marketplaces	Collaborator, WhitePress	Что невозможно вести каталоги и покупать публикации в одном месте
SEO intelligence	Ahrefs, Semrush	Что рынок готов платить за замену уже используемых rank trackers
Self-built	Google Sheets, Airtable, Python/AI scripts	Что командам сложнее собрать собственную систему, чем купить Ligora

Официальные источники: https://pitchbox.com/ ; https://linkchecker.pro/ ; https://backlinkmanager.io/ ; https://backlinkcrm.io/ ; https://www.linkody.com/ ; https://collaborator.pro/ ; https://www.whitepress.com/ ; https://ahrefs.com/ . Функции и цены могут изменяться; отсутствие описания не означает отсутствия функции.

2.3. Проверяемая гипотеза дифференциации

Institutional procurement memory: история предложений, реально оплаченных закупок, отказов, причин, гарантий и изменения цен разных поставщиков.
Strategy-to-placement traceability: от страницы и анкоров до публикации и финансовой записи.
Cross-project donor intelligence: реальный реестр всех фактических ссылок, повторных доноров и межпроектных пересечений.
Multi-dimensional financial & people analytics.
Fast spreadsheet-first adoption без полной смены процессов.

Это продуктовые гипотезы, не доказанный moat. Нет подтверждённой массовой готовности платить или продлений подписок.

2.4. Коммерческие альтернативы и gates

Исследовательские альтернативы: Full Strategy OS; Procurement-first; Paid Audit; Staged Hybrid; Workflow duplicate guard. Предлагаемые Claude ранние gates — интервью, доступ к реальным данным, подтверждённые потери, платные аудиты, точность автоматизации; поздние — оплаченные беты и повторное использование. Пороговые значения Claude не утверждены основателем и должны быть отдельно согласованы. Цены исторических тарифных гипотез Gemini ($149/$399/$990) и Claude N2 ($99/$249/$590) не являются тарифами Ligora.

3. ICP и модель организации — APPROVED

Independent / affiliate SEO teams (собственные сайты, несколько GEO, подрядчиков).
In-house SEO departments (один/несколько собственных проектов).
SEO/marketing agencies (много клиентских проектов и границы доступа).

Специализированные link-building agencies/resellers не являются стартовым ICP. External vendors не обязаны регистрироваться в Ligora.

Модели: M1 Head SEO + Specialists; M2 Head SEO + Team Leads + независимый Coordinator + vendors; M3 SEO Department + Head of LB + internal Builders (+ Coordinator); M4 SEO agency с клиентскими проектами и любой организационной схемой M1–M3. Никакая конкретная структура не навязывается всем клиентам. Strategy может отсутствовать.

4. Новое требование: multi-tenant workspace на субдомене — APPROVED

Требование TEN-01: ligora.ai — публичный сайт / точка входа; каждая организация-подписчик имеет собственное изолированное окружение client-company.ligora.ai. client-company — уникальный tenant slug. Клиент агентства (end customer/project внутри организации) не равен отдельному Ligora tenant.

TEN-02: Tenant resolution выполняется на сервере по доверенной связке hostname→tenant; tenant_id нельзя доверять из параметров URL, тела запроса или пользовательских заголовков.

TEN-03: Аутентифицированный пользователь получает доступ к tenant только через действующий membership и соответствующие grants. Разрешения обязательны на каждом API endpoint, в SQL-запросах, jobs, экспортах, импортах и отчётах.

TEN-04: Изоляция распространяется на БД, full-text search, кеши, фоновые задания, notifications, attachments, signed URLs, логи/метрики и агрегаты. Нельзя допустить утечки чужих domain names, цен, links или числа проектов через сводные endpoints.

TEN-05: Подмена Host, чужого URL/ID, tenant_id, project_id, record_id, GraphQL/REST параметров и попытки доступа к чужим объектам должны отклоняться. Использовать least privilege и отрицательные security tests с двумя tenant-фикстурами.

TEN-06: Session/cookie domain, cross-subdomain SSO, tenant switching, slug changes и custom domains потребуют отдельного security design. Сама по себе настройка DNS или subdomain не обеспечивает изоляцию.

TEN-07: Реальный способ database isolation (общая БД с tenant key + RLS, отдельная schema, отдельная DB или комбинация) ещё не утверждён. В ранних схемах были обнаружены ошибки RLS/security-invoker, поэтому нельзя копировать непроверенные snippets.

TEN-08: Отдельные tenant-scoped defaults: валюта, time zone, Link Types, Anchor Types, scoring, privacy, pricing policies, dashboards. Централизованное хранение коммерческих клиентских данных разрешено владельцем; их межклиентский обмен и ценовые бенчмарки не разрешены автоматически.

5. Новое требование: гибкая IAM / RBAC + scoped permissions — APPROVED

IAM-01: Owner/Admin, Head SEO, SEO Specialist, Head LB, Internal Builder, Coordinator, External Client/Report Viewer плюс пользовательские роли. Роль не является единственным правилом доступа.

IAM-02: Видимость задаётся на нескольких измерениях:

tenant/org membership;
роль и permissions (read/create/update/delete/approve/export/manage);
список разрешённых проектов и/или команд;
область данных (all project records / assigned tasks / own placements / client-safe reporting);
разрешённые financial/vendor/internal fields;
фильтры по клиентам и отчётам.

IAM-03: Пример стартовых шаблонов (не жёсткая модель): Head/Lead видит все проекты внутри tenant, SEO Specialist — назначенные проекты, Link Builder — назначенные проекты + собственные tasks/links, External Client — только утверждённый отчёт по проставленным ссылкам разрешённого проекта.

IAM-04: Custom Role Editor, permission presets, project grants, per-user overrides, scope preview, приглашения/отзыв доступов и история изменений прав.

IAM-05: Client Report — отдельная server-side safe projection/DTO с полями source URL, target page, anchor, link type, publication/verification dates и допустимыми статусами. Internal quoted/paid prices, vendor identities, supplier lists, agency margins, задачи и данные других проектов скрыты по умолчанию. Дополнительные доступы возможны только как явно разрешённая политика.

IAM-06: Ограничивать данные на backend, а не просто скрывать разделы/колонки CSS/JS. Search, downloads и exports обязаны соблюдать ту же политику. Текущий интерактивный сайт показывает только UX-симуляцию, не security enforcement.

IAM-07: Все действия решения и выдачи прав логируются. При удалении пользователя не уничтожаются исторические ссылки/заказы; их авторство остаётся в audit history.

6. Новое требование: Account & Billing Cabinet — APPROVED

ACC-01: Workspace Admin может просматривать subscription/tier, renewal/billing state, invoices, payment records (без выдуманной платёжной интеграции), пользователей, роли, активные seats, приглашения, проектные grants, quotas, usage и add-on purchases.

ACC-02: Только пользователи с отдельным permission manage_billing могут изменять тариф и покупать add-ons. manage_members/manage_permissions независимы от Billing.

ACC-03: Пример будущей навигации Settings → Workspace, Members & Access, Plan & Usage, Add-ons, Billing History, Security & Integrations.

ACC-04: Seats считаются по явно утверждаемым правилам. Необходимо отдельно решить, считаются ли приглашённые, suspended, client report-only и service accounts.

ACC-05: Финальные интеграции с платёжным провайдером, налогообложение, цена планов, refund/downgrade rules и валюта выставления счёта OPEN. В прототипе пакеты не оплачиваются.

7. Новое требование: тарифы + докупаемые квоты — APPROVED

LIMIT-01: Tier базово включает выбранные лимиты, например Projects, Target Pages, Keywords, Seats, Stored/Monitored Placements, Import/API Usage. Окончательный каталог лимитов требует продуктового и себестоимостного решения.

LIMIT-02: Add-on пакеты или extra usage увеличивают доступную квоту сверх базового плана. Концептуальная формула: effective_limit = base_tier_allowance + sum(active_paid_addons) + contractual_override. Измерение должно иметь свою единицу и период действия.

LIMIT-03: В кабинете доступны Used, Base, Add-on, Effective, Remaining, thresholds, expiration/renewal date, purchase history. UI не должен путать квоты проектов и число ссылок или размер хранилища.

LIMIT-04: Quota enforcement должно находиться на backend с атомарным учётом конкурентных запросов, без обхода через API, импорт, копирование проекта или параллельные сессии. Billing ledger и usage ledger разделены; права покупки отдельно проверяются.

LIMIT-05: При downgrade/exhausted allowance не удалять существующие клиентские записи автоматически. Политика grace period, запрета создания новых объектов, overage и сохранения доступа требует отдельного утверждения.

LIMIT-06: Custom enterprise contracts и prepaid/recurring packs — возможное расширение, но модель не должна быть захардкожена под три тарифа. Цены, размеры пакетов и UX-триггеры оплаты пока не утверждены.

8. Portfolio, Dashboards & Metrics — Approved principles

Global Dashboard охватывает все проекты, доступные текущей роли. Project Dashboard показывает сайт, стратегии, target pages, budgets, links, GSC/rankings, alerts. Универсальный Dashboard Builder поддерживает выбор metrics/widgets, размеры, порядок, фильтры, saved/shared views и drill-down до исходных записей.

Metrics Registry определяет семантику KPI: бюджет не складывается с allocations; количество ссылок ≠ количество доноров ≠ количество публикаций; оплачено ≠ начислено ≠ зарезервировано; position tracker ≠ GSC avg position; unknown ≠ zero. Каждый KPI учитывает разрешённый scope, coverage и freshness. Client safe dashboards не раскрывают внутренние данные.

9. Strategy & Link Planning — APPROVED

Необязательная Strategy (могут быть несколько). Link Plan может существовать самостоятельно на проекте. Target Page (URL) связывается с Keywords/Clusters, позициями, GSC, бюджетами, Plan Items. Плановая строка: page × link_type × anchor_category/exact_text × period × quantity × planned_unit_cost. Link Types и Anchor Categories расширяемы. Price policy inheritance: workspace → project → page, с отдельным target vs warning ceiling. Versioned Original Baseline / Current Plan / Actual. Невыполненное переносится без стирания исходного периода; превышения дают soft warning.

10. Donor & Vendor Intelligence — APPROVED

Один canonical Donor, множество отдельных Vendor Offers с историческими котировками, условиями, датами, типами публикации и источниками. Unified Donor Database предлагает колонki, фильтры, группировки, saved views. История отказов не теряется при новых офферах. Решения человека: Approved, Conditional, On Hold, Rejected; Not Reviewed — состояние, re-review — событие. Решения имеют контекст организации/проекта/оффера. Rule-based Scoring даёт Pass/Flagged/Insufficient Data, правила хранят версии и inputs; отсутствующие Ahrefs метрики ≠ 0. ML-scoring — future.

11. Unified Link Registry — APPROVED

Один канонический Link Registry c тремя уровнями:

Global — все разрешённые фактические ссылки всех проектов tenant.
Project — все ссылки всех типов на все страницы сайта.
Target Page — все ссылки на конкретный URL.

Разделяем Donor (root domain / host identity), Publication (source URL), Link Record (конкретная ссылка). Предупреждения: exact imported duplicate; same donor / same project; same donor / same target page; same donor / multiple target pages; same donor / cross-project; same publication / multiple links. Существующие настоящие ссылки не объединяются из-за совпадения донора. Сохраняем Lost, Changed, Unknown, live/check history, imports, vendors/builders, type, anchors, costs (content included/separate), dates, monitoring, indexation provenance. Overlap Explorer и root-domain/host/URL identity controls — предложенные UX-детали. Межпроектное обнаружение не раскрывает иные tenant или неположенные проекты.

12. Execution, Tasks, Content & Procurement — APPROVED

Минимальный пользовательский процесс: Plan/Assign → Order + optional Content → Import delivery URLs → Verify → Batch Accept / review exceptions. Не заставлять менять вручную статусы на каждой площадке. External vendors не имеют кабинета. Internal Coordinator может отличаться от Request Owner и Builder. Task/Request/Order/Publication/Link — самостоятельные сущности, но подробное ведение задач опционально.

Контент может готовить Internal Builder, External Vendor, Publisher или SEO Team; может не требоваться. Цена Included / Separate / Internal / Unknown; один контентный материал может обслуживать несколько ссылок, стоимость не дублируется. Исторические ссылки допускаются без восстановленных фиктивных заказов. Автоприёмка ограничена критериями и permissions; техническая проверка не подтверждает автоматически коммерческую приёмку.

13. Financial Intelligence — APPROVED

Аналитика всех расходов Organization → Project → Strategy → Page → Link Type/Anchor → Order/Placement, альтернативные срезы Client, Vendor, Builder, GEO, Period. Approved Budget, Allocation, Planned Cost, Committed, Incurred, Paid, Refund, Forecast — отдельные показатели. Иерархия бюджетов не суммируется дважды. Одна исходная финансовая запись распределяется через Cost Allocation. Shared/unallocated costs могут оставаться без страницы. Исторические суммы, FX rate, date и source сохраняются; soft warnings. Стоимость контента included/extra учитывается строго один раз. Неизвестные внутренние затраты не записываются автоматически $0.

14. Execution & Search Analytics — APPROVED

Plan/Fact по количеству и соответствию composition: type×anchor×page×period. Quantity completion не покрывает неисполненные типы ссылок другими типами. Link survival и историческая приёмка — независимые KPI. Search Performance: GSC clicks/impressions/CTR/avg pos, imported rankings по source/GEO/device/date, Ahrefs donor/keyword metrics в рамках доступных прав. Не утверждать SEO causality только по временной корреляции; подтверждение индексации внешних donor URLs может быть невозможно.

15. Vendor & Builder Performance — APPROVED

Отдельные vendor и internal builder rankings: supply, donor approvals, quoted/paid price, delivery, speed, reliability, durability cohorts (30/90/180/365), failures/warranties/refunds. Multi-dimensional Quality/Price/Speed/Reliability/Durability/Supply, по сравнимому контексту и с размером выборки. Нет автоматического универсального победителя. Vendor Recommendation Engine FUTURE BACKLOG.

16. Onboarding & Data Imports — APPROVED BASELINE v0.1

Поддержать запуск с нуля, готовую стратегию в Sheets/Excel и перенос многолетней истории. Excel XLSX/CSV, Google Sheets, reverse XLSX/CSV export — Stage 0. Universal Import: multi-sheet, variable headers, mapping profiles, normalization, preview, partial import, grouped exceptions, conservative dedup, idempotent reimport, provenance, audit history, safe rollback. Данные не обязаны быть полными: dashboard сразу показывает доступные разделы, не выдумывает историю. Full two-way sync Google Sheets NOT APPROVED.

17. Suggested UI & user flows — CANDIDATE

Proposed sections: Dashboard, Projects, Strategy/Planning, Link Registry, Donor Database, Execution, Analytics, Data Sources, My Work, Admin Settings. Client report is its own restricted view, not a filtered full admin dashboard.

Core UX flows:

A. Onboarding (workspace → source → map/preview → import → dashboard).
B. Strategy → assigned batch.
C. Multi-vendor pricelist → review → order.
D. Bulk delivery spreadsheet → match / technical verify → human review of exceptions → accept.
E. Portfolio KPI → project → page → link → original transaction/source.
F. Access administration → role template/custom grants → member/project assignments → permission preview.
G. Subscriber admin → plan usage → add-on pack simulation → review request to purchase with billing permission.
H. External client → server-safe authorized report only.
I. Attempt to access other subdomain/ID → denied in production authorization tests.

Detail Drawer, filters, saved views, column configuration, batch actions and minimal status updates are UX proposals consistent with approved principles. No production user interface has been built.

18. Logical Data Model — CANDIDATE

Entities (not final SQL): Tenant, Organization, Membership, Role, Permission, ProjectGrant, ReportGrant, Client, Project, Site, Strategy, StrategyVersion, TargetPage, Keyword, RankingObservation, LinkPlan, PlanItem, AnchorPolicy, PricingRule, BudgetAllocation, Donor, Host, Vendor, VendorOffer, PriceObservation, ReviewDecision, RuleEvaluation, ExecutionRequest, Assignment, Reservation, Order, OrderItem, ContentItem, Publication, LinkRecord, LinkVerification, MonitoringEvent, FinancialRecord, CostAllocation, Payment, Refund, MetricDefinition, MetricObservation, Dashboard, Widget, SavedView, DataSource, ImportBatch, MappingProfile, SourceRecord, AuditEvent, Subscription, Plan, QuotaDefinition, UsageLedger, AddOnPack, AddOnPurchase, Invoice.

Security tenant boundaries and project grants must apply consistently across entities. Search indexes and metrics must be scoped. Actual schema, constraints, write ownership, quotas and projections require dedicated engineering review.

19. Staging / Release Scope — PROPOSED

Stage 0 foundation: Tenant routing/membership + permission model + secure domain entities; functioning XLSX/CSV/Sheets import and XLSX/CSV export; idempotent mapping/provenance; link, donor and finance identity; quota usage ledger and access checks; metric dictionary and architecture-ready GSC/Ahrefs/rank adapters.

First Usable Release candidate: Global/Project dashboards, Strategy/LinkPlan, Donor Database with offers/scoring/review, three-level Link Registry and overlaps, bulk procurement/delivery/content handling, financial plan/fact, basic vendor/builder analytics, user/permissions/plan usage/admin console, client-safe report. Exact scope not approved, must pass UX and feasibility review.

Later: monitoring depth, advanced analytics, further rank adapters, scoring weighting, SLA/workload, forecasting.

Future: Vendor Recommendation Engine, ML scoring, external vendor portals, full Sheets two-way sync, comprehensive first-party rank tracker, generic workflow designer, AI dashboard generation, payroll/time tracking.

20. Decision Register

Requirement cluster	State
ICP + M1–M4, strategy-optional, flexible team roles	APPROVED
Three-level Unified Link Registry, cross-project overlaps, historical links	APPROVED
Content providers and included/separate pricing	APPROVED
Minimal/batch-first workflow, external vendors outside login	APPROVED
Excel/CSV/Sheets import and XLSX/CSV export in Stage 0	APPROVED
Tenant subdomain + data isolation	APPROVED REQUIREMENT; implementation pending
Granular role/project/link/field/report permissions	APPROVED REQUIREMENT; model pending
Account cabinet, seats, permissions and billing	APPROVED REQUIREMENT; details pending
Base plan limits + purchasable extra quota packs	APPROVED REQUIREMENT; prices/limits pending
Saved dashboards and metric drill-down	APPROVED CONCEPT; UI details pending
Ahrefs integration architecture	APPROVED CONCEPT; API approval required
Competitor market absence claims, WTP, SAM, ARPA	UNVALIDATED
UX menu and role editor details, exact tier dimensions	PROPOSED
Vendor Recommendation Engine / ML	FUTURE BACKLOG
Full two-way Sheets sync	NOT APPROVED
Production implementation/deploy	NOT AUTHORIZED

21. Acceptance / consistency test inventory

Two tenants A/B: foreign host/path/ID/record/API/export/cache/search/import/attachment/job cannot cross boundaries.
Agency client C: only granted placement-report fields and projects; no vendor identities, paid quote, margins or internal notes in API/CSV/HTML/aggregation.
SEO Specialist: only assigned projects. Builder: assigned projects and own links/tasks; owner sees workspace scope.
Custom role and project changes propagate immediately across UI and backend, auditable and non-escalating.
Concurrent quota updates never exceed contracted allowance without authorized overage; add-on purchase changes effective quota only when confirmed.
Downgrade never silently deletes existing project/page/link records; deny/new-write policy explicit.
One donor, many offers; exact duplicate import must not duplicate real records, genuine repeated placements stay distinct.
Root-domain/host/source URL/Link Record counts and overlap metrics not conflated.
One order covers three projects: allocations total equals original expense.
One content article yields multiple links: content cost counted once.
Previously rejected donor reappears: review history remains visible.
Strategy can be absent; historical links import without fake orders or invented plans.
Planned link mix cannot be artificially completed by different link types.
Verified backlink presence ≠ indexed ≠ accepted ≠ paid.
Imports 100/5,000 items without one manual status change per item; exceptions remain visible.
Missing rankings/traffic/costs displayed as unknown, not zero.
External vendors have no mandatory Ligora account.

22. Next sequence — OWNER SET ORDER

Build and inspect interactive concept website (this artifact).
Conduct Blueprint Completeness & Consistency Review only after website is assembled.
Resolve open decisions and freeze Approved Product Baseline.
UX Wireframes and user-path validation.
Technical/security architecture and separate commercial validation/go-no-go.
Separate explicit founder decision before any production code/deploy.

23. Source register

08_FOUNDER_DECISIONS_AND_ASSUMPTIONS.md — original founder constraints, including central commercial-data storage.
LIGORA_MEGA_STRATEGY_V1_DRAFT.md — research synthesis, not approved.
Gemini Stage 01–06 — initial research, several price/economic claims later corrected.
CLAUDE_00_SOURCE_INVENTORY.md — research corpus limitations.
CLAUDE_01_INDEPENDENT_AUDIT.md — errors, missing evidence and security issues.
CLAUDE_08_STRATEGIC_VERDICT.md — narrow candidate/recommended validation.
CLAUDE_09_PROPOSED_MEGA_STRATEGY_V2.md — research recommendation, not approved.
CLAUDE_10_DECISION_REGISTER_AND_VALIDATION_GATES.md — proposed evidence tests and gates.
Current founder conversations: ICP, donor DB, strategy budgets, financial intelligence, content, batch-first flow, Link Registry, custom roles, tenant subdomains, billing and extra usage.
Official references: https://pitchbox.com/pricing/ ; https://backlinkmanager.io/ ; https://linkchecker.pro/ ; https://docs.ahrefs.com/en/ahrefs-connect/docs/introduction ; https://www.linkody.com/ ; https://collaborator.pro/ ; https://www.whitepress.com/ .

End — Consolidation Candidate, not production spec or market proof.

24. Preservation of the earlier comprehensive package

Historical v0.9 source package (reference_v0.9/) accompanies the interactive site, including the old Master Blueprint, a 263-item candidate Feature Catalog in 20 functional modules, execution roadmap, founder decision table and research/evidence register. Those 263 features represent the historical FULL VISION / candidates, not 263 approved requirements. The interactive site's searchable Feature Catalog exposes them for subsequent reconciliation. v1.1 founder changes take precedence when old research or old horizon labels conflict.