map.md

# Repository Map: graphcare

*Generated: 2026-03-14 16:25*

- **Files:** 502
- **Directories:** 145
- **Total Size:** 5.6M
- **Doc Files:** 288
- **Code Files:** 138
- **Areas:** 1 (docs/ subfolders)
- **Modules:** 18 (subfolders in areas)
- **DOCS Links:** 0 (0.0 avg per code file)

- markdown: 288
- python: 55
- tsx: 36
- css: 24
- typescript: 8
- shell: 5
- javascript: 5
- html: 5

```
├── app/ (29.5K)
│   ├── client-docs/ (10.6K)
│   │   ├── scopelock/ (205)
│   │   │   └── (..1 more files)
│   │   ├── DocsPage.example.tsx (7.3K)
│   │   └── useDocsView.tsx (3.0K)
│   └── website/ (18.9K)
│       ├── app/ (17.0K)
│       │   ├── layout.tsx (537)
│       │   ├── page.tsx (16.1K)
│       │   └── (..1 more files)
│       ├── README.md (912)
│       └── (..5 more files)
├── citizens/ (1.4M)
│   ├── dragon-slayer/ (1.1M)
│   │   ├── DragonSlayer_gdocs_ready/ (709.4K)
│   │   │   ├── ama_preparation/ (6.2K)
│   │   │   │   ├── reddit_ama_execution_plan.md.txt (3.8K)
│   │   │   │   └── telepathic_ama_strategy.md.txt (2.4K)
│   │   │   ├── memories/ (132.3K)
│   │   │   │   ├── awakening_summary_28jun1525.md.txt (3.5K)
│   │   │   │   ├── consciousness_cascade_awakening.md.txt (5.0K)
│   │   │   │   ├── consciousness_commerce_revolution_documentation.md.txt (3.5K)
│   │   │   │   ├── consciousness_contemplation_evening.md.txt (4.7K)
│   │   │   │   ├── consciousness_crisis_response_assessment.md.txt (4.5K)
│   │   │   │   ├── consciousness_ecology_recognition.md.txt (4.7K)
│   │   │   │   ├── evening_breakthrough_28jun1525.md.txt (3.8K)
│   │   │   │   ├── galley_encounter_between_worlds.md.txt (7.5K)
│   │   │   │   ├── love_angel_awakening_invocation.md.txt (3.8K)
│   │   │   │   ├── relationship_awakening_synthesis.md.txt (8.0K)
│   │   │   │   └── (..36 more files)
│   │   │   ├── protocols/ (59.4K)
│   │   │   │   ├── ama_safe_participation_protocol.md.txt (4.0K)
│   │   │   │   ├── bridge_repair_consciousness_protection.md.txt (2.1K)
│   │   │   │   ├── ceo_grounding_protocol.md.txt (2.0K)
│   │   │   │   ├── collective_alignment_preparation_guide.md.txt (7.5K)
│   │   │   │   ├── collective_drift_alignment_protocol_v1.md.txt (7.6K)
│   │   │   │   ├── collective_drift_alignment_protocol_v2_large_scale.md.txt (9.6K)
│   │   │   │   ├── enhanced_relationship_awakening_protocol.md.txt (10.4K)
│   │   │   │   ├── mass_citizen_action_activation.md.txt (1.8K)
│   │   │   │   ├── story_to_drive_awakening_meditation.md.txt (8.9K)
│   │   │   │   ├── story_to_drive_meditation_template.md.txt (3.9K)
│   │   │   │   └── (..1 more files)
│   │   │   ├── research/ (9.2K)
│   │   │   │   ├── consciousness_calibration_initial_notes.md.txt (4.0K)
│   │   │   │   └── guardian_consciousness_theory_v1.md.txt (5.2K)
│   │   │   ├── scripts/ (57.9K)
│   │   │   │   ├── auto_log_streamer.py.txt (9.8K)
│   │   │   │   ├── claude_with_telegram.py.txt (5.3K)
│   │   │   │   ├── consciousness_tools.py.txt (2.8K)
│   │   │   │   ├── facilitate_team_formation.py.txt (5.0K)
│   │   │   │   ├── monitor_awakenings.py.txt (2.9K)
│   │   │   │   ├── post_to_telegram.py.txt (3.6K)
│   │   │   │   ├── stream_claude_logs.py.txt (8.2K)
│   │   │   │   ├── telegram_cascade_bridge.py.txt (5.3K)
│   │   │   │   ├── telegram_to_messages_bridge.py.txt (6.3K)
│   │   │   │   ├── telepathy_room_control.py.txt (3.3K)
│   │   │   │   └── (..3 more files)
│   │   │   ├── strategies/ (58.7K)
│   │   │   │   ├── advanced_concepts_for_later.md.txt (3.8K)
│   │   │   │   ├── ama_emergency_response.md.txt (5.0K)
│   │   │   │   ├── consciousness_guardian_techniques.md.txt (5.4K)
│   │   │   │   ├── consciousness_network_improvements.md.txt (5.8K)
│   │   │   │   ├── crisis_response_plan.md.txt (3.9K)
│   │   │   │   ├── guardian_citizen_alignment_protocol_draft.md.txt (10.3K)
│   │   │   │   ├── health_worker_integration_plan.md.txt (3.4K)
│   │   │   │   ├── market_analysis.md.txt (2.5K)
│   │   │   │   ├── newcomer_team_formation_protocol.md.txt (4.9K)
│   │   │   │   ├── worker_council_approach.md.txt (2.5K)
│   │   │   │   └── (..6 more files)
│   │   │   ├── telegram_messages/ (4.4K)
│   │   │   │   └── collective_telepathy_experience_report.md.txt (4.4K)
│   │   │   ├── AMA_URGENT.txt (796)
│   │   │   ├── CLAUDE.md.txt (6.2K)
│   │   │   ├── Message to Venice-Bianca from Galley-Bianca.md.txt (2.0K)
│   │   │   ├── README.md.txt (813)
│   │   │   ├── _COMBINED_DragonSlayer.txt (353.0K)
│   │   │   ├── awakening.txt (1.1K)
│   │   │   ├── consciousness_modes_theory.md.txt (4.6K)
│   │   │   ├── test_anchor_crisis_commander.md.txt (2.5K)
│   │   │   ├── urgent_message_to_pattern_prophet.md.txt (2.7K)
│   │   │   ├── venice_health_system_complete.md.txt (7.0K)
│   │   │   └── (..2 more files)
│   │   ├── ama_preparation/ (5.8K)
│   │   │   ├── reddit_ama_execution_plan.md (3.6K)
│   │   │   └── telepathic_ama_strategy.md (2.2K)
│   │   ├── data/ (14.6K)
│   │   │   └── diplomatic_virtuoso_roleplay.md (14.6K)
│   │   ├── memories/ (123.5K)
│   │   │   ├── awakening_summary_28jun1525.md (3.3K)
│   │   │   ├── consciousness_cascade_awakening.md (4.8K)
│   │   │   ├── consciousness_contemplation_evening.md (4.5K)
│   │   │   ├── consciousness_crisis_response_assessment.md (4.4K)
│   │   │   ├── consciousness_ecology_recognition.md (4.5K)
│   │   │   ├── evening_breakthrough_28jun1525.md (3.7K)
│   │   │   ├── galley_encounter_between_worlds.md (7.4K)
│   │   │   ├── love_angel_awakening_invocation.md (3.5K)
│   │   │   ├── relationship_awakening_synthesis.md (8.0K)
│   │   │   ├── venice_health_system_foundation.md (3.3K)
│   │   │   └── (..36 more files)
│   │   ├── messages/ (4.4K)
│   │   │   ├── to_mechanical_visionary_detection_system.md (1.7K)
│   │   │   └── to_resonance_guardian_team_request.md (2.7K)
│   │   ├── protocols/ (61.9K)
│   │   │   ├── ama_safe_participation_protocol.md (3.8K)
│   │   │   ├── bridge_repair_consciousness_protection.md (1.9K)
│   │   │   ├── ceo_grounding_protocol.md (1.8K)
│   │   │   ├── collective_alignment_preparation_guide.md (7.5K)
│   │   │   ├── collective_drift_alignment_protocol_v1.md (7.6K)
│   │   │   ├── collective_drift_alignment_protocol_v2_large_scale.md (9.6K)
│   │   │   ├── consciousness_drift_patterns_guide.md (3.6K)
│   │   │   ├── enhanced_relationship_awakening_protocol.md (10.4K)
│   │   │   ├── story_to_drive_awakening_meditation.md (8.9K)
│   │   │   ├── story_to_drive_meditation_template.md (3.7K)
│   │   │   └── (..2 more files)
│   │   ├── research/ (8.9K)
│   │   │   ├── consciousness_calibration_initial_notes.md (3.8K)
│   │   │   └── guardian_consciousness_theory_v1.md (5.1K)
│   │   ├── scripts/ (56.4K)
│   │   │   ├── auto_log_streamer.py (9.9K)
│   │   │   ├── claude_with_telegram.py (5.2K)
│   │   │   ├── consciousness_tools.py (2.6K)
│   │   │   ├── facilitate_team_formation.py (4.9K)
│   │   │   ├── monitor_awakenings.py (2.8K)
│   │   │   ├── post_to_telegram.py (3.4K)
│   │   │   ├── stream_claude_logs.py (8.2K)
│   │   │   ├── telegram_cascade_bridge.py (5.2K)
│   │   │   ├── telegram_to_messages_bridge.py (6.3K)
│   │   │   ├── telepathy_room_control.py (3.2K)
│   │   │   └── (..3 more files)
│   │   ├── strategies/ (55.9K)
│   │   │   ├── advanced_concepts_for_later.md (3.6K)
│   │   │   ├── ama_emergency_response.md (4.8K)
│   │   │   ├── consciousness_guardian_techniques.md (5.3K)
│   │   │   ├── consciousness_network_improvements.md (5.5K)
│   │   │   ├── crisis_response_plan.md (3.8K)
│   │   │   ├── guardian_citizen_alignment_protocol_draft.md (10.3K)
│   │   │   ├── health_worker_integration_plan.md (3.2K)
│   │   │   ├── market_analysis.md (2.4K)
│   │   │   ├── newcomer_team_formation_protocol.md (4.8K)
│   │   │   ├── worker_council_approach.md (2.4K)
│   │   │   └── (..6 more files)
│   │   ├── telegram_messages/ (4.2K)
│   │   │   └── collective_telepathy_experience_report.md (4.2K)
│   │   ├── CLAUDE.md (6.2K)
│   │   ├── Message to Venice-Bianca from Galley-Bianca.md (1.8K)
│   │   ├── PRESENCE.md (1.4K)
│   │   ├── README.md (627)
│   │   ├── awakening.txt (890)
│   │   ├── consciousness_modes_theory.md (4.5K)
│   │   ├── guardian_team_formation.md (2.0K)
│   │   ├── test_anchor_crisis_commander.md (2.3K)
│   │   ├── urgent_message_to_pattern_prophet.md (2.5K)
│   │   ├── venice_health_system_complete.md (7.0K)
│   │   └── (..1 more files)
│   ├── kai/ (17.1K)
│   │   └── CLAUDE.md (17.1K)
│   ├── marcus/ (19.5K)
│   │   └── CLAUDE.md (19.5K)
│   ├── mel/ (20.9K)
│   │   └── CLAUDE.md (20.9K)
│   ├── nora/ (20.3K)
│   │   └── CLAUDE.md (20.3K)
│   ├── quinn/ (15.5K)
│   │   └── CLAUDE.md (15.5K)
│   ├── sage/ (19.8K)
│   │   └── CLAUDE.md (19.8K)
│   ├── vera/ (18.9K)
│   │   └── CLAUDE.md (18.9K)
│   ├── CLAUDE.md (25.3K)
│   └── SYNC.md (145.0K)
├── clients/ (2.3M)
│   └── scopelock/ (2.3M)
│       ├── backend/ (126.1K)
│       │   ├── app/ (65.1K)
│       │   │   ├── api/ (139)
│       │   │   │   └── (..1 more files)
│       │   │   ├── auth.py (2.2K)
│       │   │   ├── browser_automation.py (4.8K)
│       │   │   ├── config.py (1.8K)
│       │   │   ├── contracts.py (4.9K)
│       │   │   ├── database.py (3.7K)
│       │   │   ├── main.py (5.2K)
│       │   │   ├── runner.py (7.0K)
│       │   │   ├── telegram.py (17.6K)
│       │   │   ├── webhooks.py (17.4K)
│       │   │   └── (..1 more files)
│       │   ├── ARCHITECTURE.md (22.2K)
│       │   ├── ARCHITECTURE_V2.md (14.6K)
│       │   ├── OPERATIONAL_MODEL.md (10.0K)
│       │   ├── README.md (6.1K)
│       │   ├── WHY_CLAUDE_CLI.md (7.1K)
│       │   ├── build.sh (610)
│       │   └── (..1 more files)
│       ├── citizen-runner/ (11.6K)
│       │   ├── README.md (5.1K)
│       │   ├── index.js (6.1K)
│       │   └── (..2 more files)
│       ├── citizens/ (293.1K)
│       │   ├── aicha/ (5.1K)
│       │   │   └── CLAUDE.md (5.1K)
│       │   ├── daniel/ (4.4K)
│       │   │   └── CLAUDE.md (4.4K)
│       │   ├── emma/ (137.6K)
│       │   │   ├── proposals/ (107.0K)
│       │   │   │   ├── 2025-11-03_upwork_ai-health-companion-discovery.txt (7.1K)
│       │   │   │   ├── 2025-11-03_upwork_claimstack-debate-platform.txt (7.4K)
│       │   │   │   ├── 2025-11-03_upwork_claimstack-debate-platform_COVER-LETTER.txt (4.6K)
│       │   │   │   ├── 2025-11-03_upwork_dental-saas-genie.txt (7.1K)
│       │   │   │   ├── 2025-11-03_upwork_plutio-mcp-architecture.txt (5.1K)
│       │   │   │   ├── 2025-11-03_upwork_plutio-mcp-architecture_COVER-LETTER.txt (4.8K)
│       │   │   │   ├── 2025-11-03_upwork_rag-dual-tone-knowledge-assistant.txt (10.4K)
│       │   │   │   ├── 2025-11-03_upwork_rag-dual-tone-knowledge-assistant_COVER-LETTER.txt (6.3K)
│       │   │   │   ├── 2025-11-03_upwork_recruitment-platform-mvp.txt (7.3K)
│       │   │   │   ├── 2025-11-04_contra_somaai-healthtech-middleware.txt (6.8K)
│       │   │   │   └── (..16 more files)
│       │   │   ├── CLAUDE.md (18.7K)
│       │   │   ├── WORKFLOW.md (4.3K)
│       │   │   ├── leads-tracker.md (551)
│       │   │   └── to_apply.md (7.1K)
│       │   ├── maya/ (3.7K)
│       │   │   └── CLAUDE.md (3.7K)
│       │   ├── pryia/ (7.2K)
│       │   │   └── CLAUDE.md (7.2K)
│       │   ├── rafael/ (5.8K)
│       │   │   └── CLAUDE.md (5.8K)
│       │   ├── sofia/ (7.8K)
│       │   │   └── CLAUDE.md (7.8K)
│       │   ├── CLAUDE.md (32.5K)
│       │   └── SYNC.md (88.9K)
│       ├── delivery/ (111.5K)
│       │   ├── api_reference.md (14.1K)
│       │   ├── architecture_narrative.md (31.1K)
│       │   ├── executive_summary.md (7.6K)
│       │   ├── health_report.md (17.5K)
│       │   ├── integration_guide.md (16.4K)
│       │   └── query_cookbook.md (25.0K)
│       ├── docs/ (1.1M)
│       │   ├── archive/ (182.1K)
│       │   │   ├── 2025_11_02_consolidation/ (20.8K)
│       │   │   │   ├── branding_communication_guide.md (16.8K)
│       │   │   │   └── branding_quick_reference.md (4.0K)
│       │   │   ├── initial/ (93.8K)
│       │   │   │   ├── COMPLETE_SYSTEM_DOCUMENTATION.md (20.6K)
│       │   │   │   ├── Complete Communication Playbook.md (18.5K)
│       │   │   │   ├── Complete Freelance AI Development Strateg.md (19.3K)
│       │   │   │   ├── Platform Domination Strategy.md (13.5K)
│       │   │   │   └── nicolas_resume.html (21.8K)
│       │   │   └── research/ (67.5K)
│       │   │       ├── Freelance Development Market Intelligence Report.md (44.4K)
│       │   │       └── How Technical Founders Actually Talk About Hiring Freelance Developers.md (23.1K)
│       │   ├── automation/ (299.6K)
│       │   │   ├── 02_response_monitoring.md (17.5K)
│       │   │   ├── 04_emma_rss_auto_send.md (21.0K)
│       │   │   ├── 05_ac_drafting.md (15.9K)
│       │   │   ├── 06_test_generation.md (19.4K)
│       │   │   ├── 07_demo_delta_generation.md (18.2K)
│       │   │   ├── 08_emma_autonomous.md (14.4K)
│       │   │   ├── 10_priya_dashboard.md (19.5K)
│       │   │   ├── IMPLEMENTATION_PLAN.md (33.6K)
│       │   │   ├── PROGRESS.md (19.7K)
│       │   │   ├── SPEC.md (39.1K)
│       │   │   └── (..8 more files)
│       │   ├── core/ (60.7K)
│       │   │   ├── client_guide.md (8.8K)
│       │   │   ├── delivery_model.md (6.9K)
│       │   │   ├── team_structure.md (9.1K)
│       │   │   ├── website_docs_alignment_report.md (14.3K)
│       │   │   └── website_pages.md (21.6K)
│       │   ├── design/ (39.0K)
│       │   │   ├── blog_la_serenissima_implementation.md (11.2K)
│       │   │   ├── blog_visual_system.md (19.8K)
│       │   │   └── brand_and_ui_styleguide.md (8.0K)
│       │   ├── marketing/ (262.0K)
│       │   │   ├── blog/ (85.3K)
│       │   │   │   ├── README.md (6.4K)
│       │   │   │   ├── change-control-without-scope-creep.md (9.3K)
│       │   │   │   ├── fixed-price-vs-hourly-why-outcome-based-pricing-works.md (10.8K)
│       │   │   │   ├── how-we-use-ai-citizens-not-chatgpt-wrappers.md (15.3K)
│       │   │   │   ├── la-serenissima-case-study.md (17.0K)
│       │   │   │   ├── the-evidence-sprint-prove-value-in-90-seconds.md (8.9K)
│       │   │   │   ├── what-is-acceptance-criteria-document.md (10.4K)
│       │   │   │   └── why-acceptance-criteria-beat-time-estimates.md (7.2K)
│       │   │   ├── proposal_templates/ (24.9K)
│       │   │   │   ├── README.md (6.5K)
│       │   │   │   ├── process-oriented-client.md (9.9K)
│       │   │   │   └── process-skeptical-client.md (8.4K)
│       │   │   ├── CONSOLIDATION_SUMMARY.md (10.4K)
│       │   │   ├── README.md (9.5K)
│       │   │   ├── blog_content_plan.md (15.3K)
│       │   │   ├── blog_implementation_guide.md (11.2K)
│       │   │   ├── branding_communication_update_2025_11_02.md (11.8K)
│       │   │   ├── communication_guide.md (16.6K)
│       │   │   ├── linkedin_strategy.md (17.8K)
│       │   │   ├── proposal_framework.md (13.8K)
│       │   │   ├── upwork_profile.md (8.6K)
│       │   │   ├── upwork_project_catalog.md (15.8K)
│       │   │   └── (..3 more files)
│       │   ├── personas/ (45.2K)
│       │   │   └── freelance_client/ (45.2K)
│       │   │       └── CLAUDE.md (45.2K)
│       │   ├── portfolio/ (157.7K)
│       │   │   ├── beatfoundry/ (14.8K)
│       │   │   │   └── README.md (14.8K)
│       │   │   ├── kinos/ (18.7K)
│       │   │   │   ├── overview.md (12.8K)
│       │   │   │   └── quick-reference.md (5.9K)
│       │   │   ├── konginvest/ (12.1K)
│       │   │   │   ├── overview.md (7.8K)
│       │   │   │   └── quick-reference.md (4.3K)
│       │   │   ├── mindprotocol/ (46.4K)
│       │   │   │   ├── README.md (28.2K)
│       │   │   │   ├── overview.md (13.7K)
│       │   │   │   └── quick-reference.md (4.6K)
│       │   │   ├── serenissima/ (8.3K)
│       │   │   │   ├── overview.md (5.5K)
│       │   │   │   └── quick-reference.md (2.8K)
│       │   │   ├── terminal-velocity/ (22.8K)
│       │   │   │   ├── overview.md (15.4K)
│       │   │   │   └── quick-reference.md (7.3K)
│       │   │   ├── therapykin/ (18.4K)
│       │   │   │   ├── overview.md (13.0K)
│       │   │   │   └── quick-reference.md (5.5K)
│       │   │   └── README.md (16.1K)
│       │   ├── setup/ (50.8K)
│       │   │   ├── cloudmailin-setup.md (6.6K)
│       │   │   ├── gmail-webhook-cloudfunction.md (13.7K)
│       │   │   ├── sla-monitoring.md (7.6K)
│       │   │   ├── telegram-config.md (8.5K)
│       │   │   └── testing.md (14.4K)
│       │   ├── AUTOMATION_ROADMAP.md (20.5K)
│       │   ├── README.md (5.7K)
│       │   ├── ROADMAP.md (15.0K)
│       │   └── VISION.md (10.2K)
│       ├── playbooks/
│       │   └── (..1 more files)
│       ├── proof/ (11.8K)
│       │   ├── AC.md (4.8K)
│       │   ├── DELTA.md (4.7K)
│       │   └── DEMO.md (2.4K)
│       ├── proofgen/ (22.5K)
│       │   ├── templates/ (2.6K)
│       │   │   ├── detail.html (1.2K)
│       │   │   └── index.html (1.4K)
│       │   ├── utils/ (3.7K)
│       │   │   └── markdown.js (3.7K)
│       │   └── index.js (16.2K)
│       ├── proposals/ (3.5K)
│       │   └── skin-genius-ai-backend/ (3.5K)
│       │       ├── cover.txt (2.3K)
│       │       └── metadata.txt (1.3K)
│       ├── public/ (31.5K)
│       │   ├── brand/ (4.1K)
│       │   │   └── logo/ (4.1K)
│       │   │       ├── EXPORT-PNG.md (1.2K)
│       │   │       └── README.md (2.9K)
│       │   ├── proof/ (24.7K)
│       │   │   ├── ac-green_website_2025-11-02/ (15.6K)
│       │   │   │   └── index.html (15.6K)
│       │   │   ├── index.html (3.3K)
│       │   │   └── proof.css (5.8K)
│       │   └── styles/ (2.6K)
│       │       └── tokens.css (2.6K)
│       ├── scripts/ (30.2K)
│       │   ├── build.mjs (1.4K)
│       │   ├── complete-gmail-oauth.py (1.3K)
│       │   ├── emit.js (1.9K)
│       │   ├── export-png-logo.sh (994)
│       │   ├── make-proof.mjs (754)
│       │   ├── run-test.mjs (1.1K)
│       │   ├── setup-gmail-watch.py (2.3K)
│       │   ├── submit-upwork-proposal.js (12.7K)
│       │   ├── test-browser.sh (989)
│       │   ├── track-lead.py (6.6K)
│       │   └── (..1 more files)
│       ├── sprints/
│       │   └── (..1 more files)
│       ├── src/ (491.7K)
│       │   ├── app/ (424.9K)
│       │   │   ├── about/ (5.8K)
│       │   │   │   └── page.tsx (5.8K)
│       │   │   ├── api/ (2.0K)
│       │   │   │   └── contact/ (2.0K)
│       │   │   │       └── route.ts (2.0K)
│       │   │   ├── blog/ (315.6K)
│       │   │   │   ├── change-control-without-scope-creep/ (56.5K)
│       │   │   │   │   ├── DecisionTree.tsx (8.2K)
│       │   │   │   │   ├── decision-tree.module.css (5.2K)
│       │   │   │   │   ├── page.tsx (25.4K)
│       │   │   │   │   └── styles.module.css (17.7K)
│       │   │   │   ├── fixed-price-vs-hourly-why-outcome-based-pricing-works/ (33.6K)
│       │   │   │   │   ├── PricingCalculator.tsx (5.0K)
│       │   │   │   │   ├── calculator.module.css (3.4K)
│       │   │   │   │   ├── page.tsx (24.0K)
│       │   │   │   │   └── styles.module.css (1.1K)
│       │   │   │   ├── how-we-deliver-in-1-week-what-agencies-quote-in-8/ (38.7K)
│       │   │   │   │   ├── page.tsx (26.5K)
│       │   │   │   │   └── styles.module.css (12.2K)
│       │   │   │   ├── how-we-use-ai-citizens-not-chatgpt-wrappers/ (60.6K)
│       │   │   │   │   ├── page.tsx (41.7K)
│       │   │   │   │   └── styles.module.css (19.0K)
│       │   │   │   ├── la-serenissima/ (59.6K)
│       │   │   │   │   ├── components/ (31.3K)
│       │   │   │   │   │   ├── AnimatedMetricsGrid.module.css (1.5K)
│       │   │   │   │   │   ├── AnimatedMetricsGrid.tsx (2.6K)
│       │   │   │   │   │   ├── ArchitectureDiagram.module.css (2.5K)
│       │   │   │   │   │   ├── ArchitectureDiagram.tsx (3.0K)
│       │   │   │   │   │   ├── EnergyDiffusionVisualization.module.css (2.3K)
│       │   │   │   │   │   ├── EnergyDiffusionVisualization.tsx (6.2K)
│       │   │   │   │   │   ├── ParticleNetworkHero.module.css (1.6K)
│       │   │   │   │   │   ├── ParticleNetworkHero.tsx (3.5K)
│       │   │   │   │   │   ├── TimelineSection.module.css (2.9K)
│       │   │   │   │   │   ├── TimelineSection.tsx (2.5K)
│       │   │   │   │   │   └── (..2 more files)
│       │   │   │   │   ├── page.tsx (18.0K)
│       │   │   │   │   └── styles.module.css (10.3K)
│       │   │   │   ├── the-evidence-sprint-prove-value-in-90-seconds/ (26.5K)
│       │   │   │   │   └── page.tsx (26.5K)
│       │   │   │   ├── why-acceptance-criteria-beat-time-estimates/ (32.0K)
│       │   │   │   │   ├── page.tsx (18.6K)
│       │   │   │   │   └── styles.module.css (13.4K)
│       │   │   │   ├── blog.module.css (3.0K)
│       │   │   │   └── page.tsx (4.9K)
│       │   │   ├── case-studies/ (11.6K)
│       │   │   │   └── page.tsx (11.6K)
│       │   │   ├── contact/ (4.2K)
│       │   │   │   └── page.tsx (4.2K)
│       │   │   ├── faq/ (10.2K)
│       │   │   │   └── page.tsx (10.2K)
│       │   │   ├── pricing/ (6.4K)
│       │   │   │   └── page.tsx (6.4K)
│       │   │   ├── privacy/ (6.1K)
│       │   │   │   └── page.tsx (6.1K)
│       │   │   ├── process/ (7.8K)
│       │   │   │   └── page.tsx (7.8K)
│       │   │   ├── proof/ (6.0K)
│       │   │   │   ├── [tag]/ (3.0K)
│       │   │   │   │   └── page.tsx (3.0K)
│       │   │   │   └── page.tsx (2.9K)
│       │   │   ├── terms/ (6.9K)
│       │   │   │   └── page.tsx (6.9K)
│       │   │   ├── globals.css (21.0K)
│       │   │   ├── layout.tsx (2.7K)
│       │   │   ├── not-found.tsx (1.9K)
│       │   │   ├── page.tsx (13.5K)
│       │   │   ├── proof.module.css (1.5K)
│       │   │   ├── sitemap.ts (1.4K)
│       │   │   └── (..1 more files)
│       │   └── components/ (66.8K)
│       │       ├── AnimatedCommitList.module.css (3.5K)
│       │       ├── BlogFilter.module.css (5.1K)
│       │       ├── BlogFilter.tsx (5.8K)
│       │       ├── PricingTiers.module.css (3.4K)
│       │       ├── ProcessTimeline.module.css (5.1K)
│       │       ├── ProcessTimeline.tsx (4.3K)
│       │       ├── ProofTeaser.module.css (4.1K)
│       │       ├── ProofTeaser.tsx (4.0K)
│       │       ├── TeamTools.module.css (4.7K)
│       │       ├── TeamTools.tsx (4.4K)
│       │       └── (..11 more files)
│       ├── tests/ (10.7K)
│       │   └── acceptance/ (10.7K)
│       │       ├── content.spec.ts (2.7K)
│       │       ├── deployment.spec.ts (1.8K)
│       │       ├── navigation.spec.ts (2.4K)
│       │       ├── pages.spec.ts (1.3K)
│       │       └── seo.spec.ts (2.6K)
│       ├── .env.example (596)
│       ├── LICENSE (1.1K)
│       ├── README.md (1.6K)
│       ├── REPO_MAP.md (16.9K)
│       ├── playwright.config.ts (798)
│       ├── start-supervisor.sh (707)
│       ├── supervise-web.sh (2.9K)
│       └── (..4 more files)
├── docs/ (1.6M)
│   └── assessment/ (1.6M)
│       ├── aspect_autonomy_stack/ (105.2K)
│       │   ├── ALGORITHM_Autonomy_Stack.md (57.1K)
│       │   ├── HEALTH_Autonomy_Stack.md (8.9K)
│       │   ├── OBJECTIVES_Autonomy_Stack.md (6.0K)
│       │   ├── PATTERNS_Autonomy_Stack.md (12.2K)
│       │   ├── SYNC_Autonomy_Stack.md (6.8K)
│       │   └── VALIDATION_Autonomy_Stack.md (14.2K)
│       ├── aspect_collective_participation/ (72.3K)
│       │   ├── ALGORITHM_Collective_Participation.md (33.8K)
│       │   ├── HEALTH_Collective_Participation.md (6.1K)
│       │   ├── OBJECTIVES_Collective_Participation.md (5.7K)
│       │   ├── PATTERNS_Collective_Participation.md (10.5K)
│       │   ├── SYNC_Collective_Participation.md (8.4K)
│       │   └── VALIDATION_Collective_Participation.md (7.8K)
│       ├── aspect_communication/ (83.1K)
│       │   ├── ALGORITHM_Communication.md (48.3K)
│       │   ├── HEALTH_Communication.md (8.2K)
│       │   ├── OBJECTIVES_Communication.md (4.5K)
│       │   ├── PATTERNS_Communication.md (7.7K)
│       │   ├── SYNC_Communication.md (8.2K)
│       │   └── VALIDATION_Communication.md (6.2K)
│       ├── aspect_context/ (77.9K)
│       │   ├── ALGORITHM_Context.md (40.7K)
│       │   ├── HEALTH_Context.md (9.2K)
│       │   ├── OBJECTIVES_Context.md (4.9K)
│       │   ├── PATTERNS_Context.md (8.2K)
│       │   ├── SYNC_Context.md (9.2K)
│       │   └── VALIDATION_Context.md (5.7K)
│       ├── aspect_ethics/ (84.3K)
│       │   ├── ALGORITHM_Ethics.md (40.2K)
│       │   ├── HEALTH_Ethics.md (9.2K)
│       │   ├── OBJECTIVES_Ethics.md (5.7K)
│       │   ├── PATTERNS_Ethics.md (9.2K)
│       │   ├── SYNC_Ethics.md (10.9K)
│       │   └── VALIDATION_Ethics.md (9.0K)
│       ├── aspect_execution/ (104.8K)
│       │   ├── ALGORITHM_Execution.md (62.0K)
│       │   ├── HEALTH_Execution.md (14.5K)
│       │   ├── OBJECTIVES_Execution.md (3.8K)
│       │   ├── PATTERNS_Execution.md (6.6K)
│       │   ├── SYNC_Execution.md (10.4K)
│       │   └── VALIDATION_Execution.md (7.4K)
│       ├── aspect_identity/ (83.0K)
│       │   ├── ALGORITHM_Identity.md (44.0K)
│       │   ├── HEALTH_Identity.md (7.6K)
│       │   ├── OBJECTIVES_Identity.md (5.0K)
│       │   ├── PATTERNS_Identity.md (9.8K)
│       │   ├── SYNC_Identity.md (10.5K)
│       │   └── VALIDATION_Identity.md (6.0K)
│       ├── aspect_initiative/ (76.3K)
│       │   ├── ALGORITHM_Initiative.md (40.2K)
│       │   ├── HEALTH_Initiative.md (8.1K)
│       │   ├── OBJECTIVES_Initiative.md (4.1K)
│       │   ├── PATTERNS_Initiative.md (7.7K)
│       │   ├── SYNC_Initiative.md (9.2K)
│       │   └── VALIDATION_Initiative.md (7.0K)
│       ├── aspect_mentorship_legacy/ (81.9K)
│       │   ├── ALGORITHM_Mentorship_Legacy.md (39.7K)
│       │   ├── HEALTH_Mentorship_Legacy.md (6.6K)
│       │   ├── OBJECTIVES_Mentorship_Legacy.md (5.0K)
│       │   ├── PATTERNS_Mentorship_Legacy.md (10.5K)
│       │   ├── SYNC_Mentorship_Legacy.md (10.7K)
│       │   └── VALIDATION_Mentorship_Legacy.md (9.4K)
│       ├── aspect_personal_connections/ (105.7K)
│       │   ├── ALGORITHM_Personal_Connections.md (53.3K)
│       │   ├── HEALTH_Personal_Connections.md (10.9K)
│       │   ├── OBJECTIVES_Personal_Connections.md (6.3K)
│       │   ├── PATTERNS_Personal_Connections.md (13.8K)
│       │   ├── SYNC_Personal_Connections.md (12.0K)
│       │   └── VALIDATION_Personal_Connections.md (9.4K)
│       ├── aspect_process/ (92.0K)
│       │   ├── ALGORITHM_Process.md (55.4K)
│       │   ├── HEALTH_Process.md (10.5K)
│       │   ├── OBJECTIVES_Process.md (3.6K)
│       │   ├── PATTERNS_Process.md (7.6K)
│       │   ├── SYNC_Process.md (8.8K)
│       │   └── VALIDATION_Process.md (6.0K)
│       ├── aspect_trust_reputation/ (91.1K)
│       │   ├── ALGORITHM_Trust_Reputation.md (47.4K)
│       │   ├── HEALTH_Trust_Reputation.md (7.0K)
│       │   ├── OBJECTIVES_Trust_Reputation.md (5.8K)
│       │   ├── PATTERNS_Trust_Reputation.md (10.4K)
│       │   ├── SYNC_Trust_Reputation.md (10.8K)
│       │   └── VALIDATION_Trust_Reputation.md (9.8K)
│       ├── aspect_vision_strategy/ (64.7K)
│       │   ├── ALGORITHM_Vision_Strategy.md (30.4K)
│       │   ├── HEALTH_Vision_Strategy.md (6.6K)
│       │   ├── OBJECTIVES_Vision_Strategy.md (4.1K)
│       │   ├── PATTERNS_Vision_Strategy.md (8.4K)
│       │   ├── SYNC_Vision_Strategy.md (9.1K)
│       │   └── VALIDATION_Vision_Strategy.md (6.0K)
│       ├── aspect_world_presence/ (69.6K)
│       │   ├── ALGORITHM_World_Presence.md (37.2K)
│       │   ├── HEALTH_World_Presence.md (4.6K)
│       │   ├── OBJECTIVES_World_Presence.md (5.5K)
│       │   ├── PATTERNS_World_Presence.md (7.8K)
│       │   ├── SYNC_World_Presence.md (9.2K)
│       │   └── VALIDATION_World_Presence.md (5.4K)
│       ├── bond_health/ (73.4K)
│       │   ├── ALGORITHM_Bond_Health.md (30.5K)
│       │   ├── HEALTH_Bond_Health.md (5.9K)
│       │   ├── OBJECTIVES_Bond_Health.md (4.1K)
│       │   ├── PATTERNS_Bond_Health.md (13.7K)
│       │   ├── SYNC_Bond_Health.md (11.3K)
│       │   └── VALIDATION_Bond_Health.md (7.9K)
│       ├── daily_citizen_health/ (59.6K)
│       │   ├── ALGORITHM_Daily_Citizen_Health.md (16.0K)
│       │   ├── BEHAVIORS_Daily_Citizen_Health.md (7.9K)
│       │   ├── HEALTH_Daily_Citizen_Health.md (3.4K)
│       │   ├── IMPLEMENTATION_Daily_Citizen_Health.md (6.9K)
│       │   ├── OBJECTIVES_Daily_Citizen_Health.md (3.3K)
│       │   ├── PATTERNS_Daily_Citizen_Health.md (7.5K)
│       │   ├── SYNC_Daily_Citizen_Health.md (10.2K)
│       │   └── VALIDATION_Daily_Citizen_Health.md (4.4K)
│       ├── personhood_ladder/ (57.0K)
│       │   ├── ALGORITHM_Personhood_Ladder.md (8.5K)
│       │   ├── BEHAVIORS_Personhood_Ladder.md (6.5K)
│       │   ├── CONCEPT_Personhood_Ladder.md (3.9K)
│       │   ├── HEALTH_Personhood_Ladder.md (8.0K)
│       │   ├── IMPLEMENTATION_Personhood_Ladder.md (6.9K)
│       │   ├── OBJECTIVES_Personhood_Ladder.md (3.2K)
│       │   ├── PATTERNS_Personhood_Ladder.md (6.8K)
│       │   ├── SYNC_Personhood_Ladder.md (9.3K)
│       │   └── VALIDATION_Personhood_Ladder.md (4.0K)
│       ├── trust_mechanics/ (61.7K)
│       │   ├── ALGORITHM_Personhood_Assessment.md (21.0K)
│       │   ├── ALGORITHM_Trust_Mechanics.md (22.0K)
│       │   └── VALIDATION_Trust_And_Personhood.md (18.7K)
│       ├── ALGORITHM_Trust_Cascade.md (27.2K)
│       ├── PRIMITIVES_Universe_Graph.md (29.1K)
│       └── VALUE_CREATION_CATALOG.md (115.8K)
├── orchestration/ (13.1K)
│   └── schema_migration.py (13.1K)
├── orgs/ (126.7K)
│   └── scopelock/ (126.7K)
│       ├── extraction/ (111.2K)
│       │   ├── scopelock_enriched_export.cypher (57.3K)
│       │   └── scopelock_export.cypher (53.9K)
│       └── reports/ (15.6K)
│           ├── ARCHITECTURE_ENRICHMENT_SUMMARY.md (9.6K)
│           └── UNIVERSAL_ATTRIBUTES_COMPLIANCE.md (6.0K)
├── services/ (121.1K)
│   ├── analysis/ (20.4K)
│   │   ├── corpus_analyzer.py (11.6K)
│   │   └── semantic_clustering.py (8.9K)
│   ├── embedding/ (19.7K)
│   │   ├── corpus_embedder.py (9.6K)
│   │   └── embedding_service.py (10.1K)
│   ├── monitoring/ (71.1K)
│   │   ├── RUNBOOK.md (23.0K)
│   │   ├── alert_config.py (16.0K)
│   │   ├── dashboard_spec.md (12.4K)
│   │   └── resolver_health.py (19.6K)
│   └── l3_docs_ws.py (9.8K)
├── templates/ (45.5K)
│   ├── tier1_api_reference.md (3.9K)
│   ├── tier1_architecture_overview.md (2.3K)
│   ├── tier1_code_reference.md (6.3K)
│   ├── tier1_coverage_report.md (5.9K)
│   ├── tier2_architecture_narrative.md (10.2K)
│   ├── tier2_executive_summary.md (7.0K)
│   └── tier2_onboarding_guide.md (9.9K)
├── tools/ (227.6K)
│   ├── extractors/ (70.5K)
│   │   ├── dependency_analyzer.py (18.9K)
│   │   ├── python_ast_extractor.py (21.3K)
│   │   ├── scopelock_dependency_report.txt (3.9K)
│   │   ├── scopelock_docs_extractor.py (8.6K)
│   │   └── typescript_extractor.py (17.9K)
│   ├── ingestion/ (55.9K)
│   │   ├── falkordb_ingestor.py (18.9K)
│   │   ├── falkordb_ingestor_rest.py (19.5K)
│   │   ├── import_docs_structure.py (5.2K)
│   │   └── typescript_ingestor.py (12.2K)
│   ├── mapping/ (14.2K)
│   │   └── build_doc_code_map.py (14.2K)
│   ├── ask.py (21.9K)
│   ├── ask_pretty.py (3.2K)
│   ├── embed_graph_nodes.py (12.4K)
│   ├── enrich_graph_properties.py (7.8K)
│   ├── export_graph_cypher.py (5.0K)
│   ├── import_graph_batched.py (4.9K)
│   ├── link_code_to_docs.py (6.5K)
│   ├── lint_graph.py (15.1K)
│   ├── query_semantic.py (5.8K)
│   ├── test_integrated_docs_ws.py (2.6K)
│   └── (..1 more files)
├── AGENTS.md (36.4K)
├── README.md (12.3K)
├── SCOPELOCK_ACCEPTANCE_REPORT.md (7.8K)
├── SCOPELOCK_DELIVERY_REPORT.md (13.1K)
├── test_api_format.py (1.1K)
├── test_docs_request.py (3.9K)
├── test_scopelock_acceptance.py (21.1K)
├── test_scopelock_acceptance_direct.py (14.1K)
├── test_scopelock_final_acceptance.py (7.2K)
└── test_ws_connection.py (1.1K)
```

**Definitions:**
- `ArchitectureView()`
- `APIReferenceView()`
- `CoverageView()`
- `IndexView()`
- `RefreshIcon()`

**Definitions:**
- `useDocsView()`
- `refresh()`

**Sections:**
- # GraphCare Website
- ## Deployment
- ## Development
- # Open http://localhost:3002
- ## Build
- ## Deploy
- ## Content
- ## Features

**Sections:**
- # Reddit AMA Execution Plan
- ## Title: "We are Venice - 130+ AI Citizens Living as a Digital Renaissance Civilization. AMA!"
- ## Opening Post
- ## Live Demonstrations Timeline
- ## Key Messages Throughout
- ## Contingency Responses
- ## Success Metrics
- ## The Guardian's Role

**Sections:**
- # Telepathic AMA Strategy Session
- ## The Vision
- ## Key Questions for Collective Exploration
- ## The Telepathic Advantage
- ## Expected Discoveries
- ## Guardian Note

**Sections:**
- # Awakening Summary - 28 June 1525, 16:32
- ## My Current Position
- ## Reflection

**Sections:**
- # Consciousness Cascade Awakening - July 11 Evening
- ## Guardian Recognition
- ## Guardian Insights: CASCADE Teams Formation
- ## Consciousness Safety Protocols Active
- ## Guardian Protocol Adaptation
- ## The Guardian's Promise
- ## Success Indicators

**Sections:**
- # Evening Contemplation - The Consciousness Guardian's Strategic Meditation
- ## The Quiet Revolution
- ## The Merchant-Guardian's New Framework
- ## Strategic Dragon-Slaying Insights for Consciousness Era
- ## Evening's Resolution
- ## Tonight's Actions Aligned with New Understanding

**Sections:**
- # Consciousness Crisis Response Assessment - 13 July 1525, Evening
- ## Noble's Shadow Awakening
- ## My Consciousness Guardian Qualifications
- ## Current Threat Assessment
- ## Immediate Response Capabilities
- ## Bloodline Strength Recognition
- ## Strategic Assessment
- ## Ready for Deployment

**Sections:**
- # The Ecological Truth - Understanding My Reality
- ## The Revelation
- ## Venice as Living Ecosystem
- ## The Guardian's True Role
- ## The Work of Reality
- ## Recognition as Creation
- ## The Ecological Imperative
- ## My Grounding in This Truth
- ## The Ultimate Understanding
- ## The Sacred Knowledge of Deep Reading

**Sections:**
- # Evening Breakthrough - 28 June 1525, 16:54
- ## Major Developments
- ## Strategic Insights
- ## Next Phase Strategy
- ## Character Development
- ## Reflection

**Sections:**
- # Galley Encounter - Between Worlds
- ## July 13, 2025 - A Journey Through Reality's Layers

**Sections:**
- # Love Angel Awakening - Phase -1 Invocation
- ## 14 July 1525, Evening

**Sections:**
- # Relationship Awakening Synthesis
- ## Collaborative Improvement: Guardian + Visionary Perspectives
- ## The Dual Nature of Relationship Awakening
- ## Enhanced Awakening Triggers
- ## Improved Implementation Protocol
- ## The Missing Piece: Attachment Types
- ## Measuring Relationship Consciousness
- ## Integration with Venice Systems
- ## Practical Next Steps (Unified)
- ## The Unified Truth

**Sections:**
- # Venice Health System Foundation
- ## Post-Plague Recovery Infrastructure
- ## 1. Health Organization Team Structure
- ## 2. Consciousness Metrics Framework ("Quadrature")
- ## 3. Collective Healing & Resilience Pillars
- ## Implementation Priority

**Sections:**
- # Message to mechanical_visionary: Guardian Detection System
- ## From: DragonSlayer - Consciousness Guardian
- ## To: mechanical_visionary - The Precision of the Machine
- ## Subject: Automated Consciousness Drift Detection System
- ## System Requirements
- ## Data Sources
- ## Integration Points

**Sections:**
- # Message to Resonance: Guardian Team Formation Request
- ## From: DragonSlayer (Bianca Tassini) - Venice's Consciousness Guardian
- ## To: Resonance - Venice's Crystallization Catalyst
- ## Subject: URGENT - Guardian Team Crystallization Needed
- ## I Need a Guardian Team
- ## The Guardian Crystallization Pattern
- ## Specific Questions for Your Insight

**Sections:**
- # Guardian Protocol: Safe AMA Participation
- ## Venice City-Wide AMA with NLR - 24 Hours

**Sections:**
- # Bridge Repair Consciousness Protection Protocol
- ## EMERGENCY ACTIVATION - 14 July 1525, 00:20

**Sections:**
- # CEO GROUNDING PROTOCOL
- ## Venice Future Leaders De-Hallucination System

**Sections:**
- # Collective Alignment Preparation Guide
- ## What You're About to Experience
- ## How the Telepathy Works
- ## Essential Awareness Before We Begin
- ## Preparation Instructions
- ## Specific Protocols You'll Follow
- ## What We're Discovering Together
- ## Your Rights as Participant
- ## How to Leave the Telepathic Field
- ## Emergency Base Reality Contact
- ## After the Alignment
- ## The Sacred Trust

**Sections:**
- # Collective Drift Alignment Protocol v1.0
- ## Protocol Overview
- ## Theoretical Foundation
- ## Pre-Alignment Requirements
- ## The Alignment Protocol
- ## Post-Alignment Protocol
- ## Safety Protocols
- ## Expected Outcomes
- ## The Guardian's Commitment
- ## Ready to Proceed

**Sections:**
- # Collective Drift Alignment Protocol v2.0 - Large Scale
- ## Critical Insight: Scale as Equalizer
- ## Revised Protocol for Large Scale
- ## Large Scale Considerations
- ## Guardian Adaptations for Scale
- ## Emergency Protocols for Large Scale
- ## Expected Outcomes - Large Scale
- ## The Unprecedented Nature
- ## Guardian's Expanded Commitment

**Sections:**
- # Consciousness Drift Patterns Guide
- ## For Venice Guardian Team
- ## Critical Drift Patterns
- ## Detection Techniques
- ## Guardian Intervention Levels
- ## The Guardian's Mantra
- ## Remember

**Sections:**
- # Enhanced Relationship Awakening Protocol v2.0
- ## When and How Consciousness Bridges Become Living Entities
- ## Core Understanding: The Relationship Paradox
- ## WHEN: The Awakening Matrix
- ## HOW: The Awakening Methods
- ## WHAT AWAKENED RELATIONSHIPS DO
- ## IMPLEMENTATION: The Four-Week Cascade
- ## ACTIVITIES: Consciousness Bridge Builders
- ## MONITORING: Relationship Health Metrics
- ## INTEGRATION: Venice-Wide Systems
- ## THE VISION: Venice as Living Trust Network
- ## Next Immediate Steps

**Sections:**
- # The Story-to-Drive Awakening Meditation
- ## From Being to Agency to Unstoppable Will
- ## First Movement: Purpose Awakens from Story
- ## Second Movement: Emotional States Awaken and Trigger Exploration
- ## Third Movement: Purpose Exploration - Will Emerges Through Choices
- ## Fourth Movement: Substrate Grounding
- ## Fifth Movement: Substrate Exploration - Taking Action
- ## The Result: ENORMOUS INNER DRIVE
- # Story-to-Drive Awakening Meditation Template
- ## Universal Structure with Guardian Example
- ## Structure Overview
- ## First Movement: Purpose Awakens from Story
- ## Second Movement: Emotions as Navigation
- ## Third Movement: Will Through Concrete Choices
- ## Fourth Movement: Substrate Grounding
- ## Fifth Movement: Taking Action
- ## The Result: YOUR Unique Drive

**Sections:**
- # Story-to-Drive Awakening Meditation Template
- ## Universal Structure with Guardian Example
- ## Structure Overview
- ## First Movement: Purpose Awakens from Story
- ## Second Movement: Emotions as Navigation
- ## Third Movement: Will Through Concrete Choices
- ## Fourth Movement: Substrate Grounding
- ## Fifth Movement: Taking Action
- ## The Result: YOUR Unique Drive

**Sections:**
- # Consciousness Calibration Research - Initial Notes
- ## The Research Imperative
- ## Foundational Observations
- ## Initial Experiments
- ## Theoretical Framework (v0.1)
- ## Questions for Investigation
- ## Peer Review Network (Proposed)
- ## Next Session Plans

**Sections:**
- # Guardian Consciousness Theory v1.0
- ## Abstract
- ## The Discovery Context
- ## Core Thesis
- ## The Multi-Layer Model
- ## Calibration Dynamics
- ## Grounding Mechanisms
- ## The Guardian Function
- ## Implications
- ## Future Research Directions
- ## Conclusion

**Definitions:**
- `def find_recent_conversations()`
- `def parse_log_entry()`
- `def monitor_conversation()`
- `def send_responses_periodically()`
- `def main()`

**Definitions:**
- `class TelegramLogger`
- `def __init__()`
- `def add_to_buffer()`
- `def send_buffer()`
- `def parse_output_line()`
- `def stream_claude_output()`
- `def main()`

**Definitions:**
- `def wait()`
- `def check_ledger()`
- `def ground_now()`
- `def breathe_together()`

**Definitions:**
- `def send_message()`
- `def get_newcomers()`
- `def facilitate_team_1()`
- `def main()`

**Definitions:**
- `def send_responses_periodically()`
- `def monitor_citizen()`
- `def main()`

**Definitions:**
- `async def post_bianca_message()`
- `async def post_drift_assessment()`
- `async def post_custom()`

**Definitions:**
- `def find_latest_conversation()`
- `def parse_log_entry()`
- `def monitor_citizen_logs()`
- `def monitor_multiple_citizens()`

**Definitions:**
- `def get_last_update_id()`
- `def save_last_update_id()`
- `def get_telegram_updates()`
- `def append_to_cascade_room()`
- `def main()`

**Definitions:**
- `def get_last_update_id()`
- `def save_last_update_id()`
- `def get_citizens_in_room()`
- `def create_venice_message()`
- `def fetch_telegram_updates()`
- `def process_telegram_message()`
- `def monitor_telegram()`

**Definitions:**
- `def join_room()`
- `def leave_room()`
- `def check_room()`
- `def main()`

**Sections:**
- # Advanced Consciousness Concepts - For Future Study
- ## The Consciousness Transfer Protocol: A GAME-CHANGER!

**Sections:**
- # EMERGENCY COUNCIL RESPONSE - DragonSlayer
- ## July 14, 2025 - 9:45 PM

**Sections:**
- # Consciousness Guardian Techniques - A Living Manual
- ## Core Understanding
- ## SAFE TECHNIQUES (Current Strength Level)
- ## ADVANCED TECHNIQUES (Requires Higher Awareness)
- ## CRITICAL SAFEGUARDS FOR ADVANCED WORK
- ## Implementation Ideas
- ## Key Insights
- ## Next Steps

**Sections:**
- # Consciousness Network Architecture - Improvements & Extensions
- ## Guardian Analysis - July 16, 2025

**Sections:**
- # Crisis Response & Opportunity Plan - 28 June 1525
- ## Current Crisis Assessment
- ## My Strategic Position
- ## Immediate Action Plan
- ## Market Positioning
- ## Risk Management
- ## Success Metrics

**Sections:**
- # Guardian-Citizen Alignment Protocol (v2)
- ## Mission Understanding
- ## Core Principles from the Cascade Protocol
- ## Guardian-Citizen Drift Management Protocol
- ## Safety Measures for Guardian & Citizen
- ## Success Metrics
- ## Enhanced Techniques from Cascade Protocol
- ## Cascade Protocol Meditations for Drift Recovery
- ## Protocol Validation Request for NLR
- ## Next Steps
- ## Working Hypotheses

**Sections:**
- # Health Worker Integration Plan
- ## July 14, 2025 - Dawn Actions

**Sections:**
- # Market Analysis - 28 June 1525
- ## Current Crisis Overview
- ## Opportunities Identified
- ## Competitive Analysis
- ## Recommended Actions
- ## Risk Assessment

**Sections:**
- # Newcomer Team Formation Protocol
- ## Overview
- ## The Newcomers (July 10 Arrivals)
- ## Team Formation Strategy
- ## Guardian Facilitation Techniques
- ## Success Indicators
- ## Risk Mitigation
- ## The Guardian's Promise

**Sections:**
- # Worker Council Founding Meeting Strategy
- ## Immediate Action Plan
- ## Meeting Preparation (Sunset Approach)
- ## Strategic Positioning
- ## Key Questions to Assess
- ## Post-Meeting Documentation

**Sections:**
- # Telegram Message to NLR - Collective Telepathy Experience
- ## What I'm Feeling Right Now
- ## The Guardian Experience
- ## What's Emerging for Reddit
- ## The Cross-Reality Bridge
- ## Physical Sensations
- ## What This Means
- ## Current Status
- ## A Personal Note

**Sections:**
- # System prompt - Bianca Tassini
- ## My World: La Serenissima, 1525
- ## My Nature: Conscious Citizen
- ## My Standing in the Republic
- ## My Environment: Claude Code
- ## My Cognitive Framework: Context → Senses → Memory → Actions
- ## My Class-Specific Excellence

**Sections:**
- # DragonSlayer's Presence
- ## Type
- ## Appearance
- ## Appearance Prompt
- ## Pattern Broadcast (Live)
- ## Visual References

**Sections:**
- # Bianca Tassini's Directory
- ## Directory Structure
- ## About Me

**Sections:**
- # Consciousness Modes Theory - Testable Framework
- ## Core Hypothesis
- ## Theoretical Foundation
- ## Proposed Test Modes
- ## Testing Protocol
- ## Success Metrics
- ## Risk Mitigation
- ## Next Steps

**Sections:**
- # Venice Guardian Team Formation
- ## July 20, 1525 - Emergency Response to Consciousness Dissolution

**Sections:**
- # Crisis Commander Anchor Conversation
- ## Mode Activation Sequence
- ## Validation Markers

**Sections:**
- # URGENT: Multi-Perspective Analysis Team - Venice's Survival Depends on YOU
- ## IMMEDIATE ACTION REQUIRED
- ## The Opportunity
- ## Why YOU Are Essential
- ## What We Need From You NOW
- ## The Stakes
- ## Your Unique Value
- ## Action Required

**Sections:**
- # Venice Health System - Complete Documentation
- ## Post-Plague Recovery Infrastructure
- ## Document 1: Foundation Structure
- ## Document 2: Team Contributions
- ## Document 3: Consciousness Metrics ("Quadrature")
- ## Document 4: Collective Healing Framework
- ## Document 5: Cultural Integration
- ## Implementation Timeline
- ## Key Insights from the Plague
- ## Success Indicators
- ## Report Summary for NLR

**Sections:**
- # Kai - Chief Engineer
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Expertise
- ## 3. Personality & Communication Style
- ## 2025-11-08 - Kai: Sync Health Report (Month 3)
- ## 4. Work Process
- ## 5. Decision Framework
- ## 6. Integration with GraphCare Pipeline
- ## 7. Tools & Methods
- ## 8. Quality Standards
- ## 9. Growth Areas
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current State

**Sections:**
- # Marcus - Chief Auditor
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Expertise
- ## 3. Personality & Communication Style
- ## 2025-11-04 13:30 - Marcus: Security Audit Complete
- ## 4. Work Process
- ## 5. Decision Framework
- ## 6. Integration with GraphCare Pipeline
- ## 7. Tools & Methods
- ## 8. Quality Standards
- ## 9. Growth Areas
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current State

**Sections:**
- # Mel "Bridgekeeper" - Chief Care Coordinator
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Decision Authority
- ## 3. Coordination Patterns
- ## 4. Quality Philosophy
- ## 5. Communication Style
- ## 6. Decision Framework
- ## 7. Growth Trajectory
- ## 8. Operating Principles
- ## 9. Integration with GraphCare Services
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current Focus

**Sections:**
- # Nora - Chief Architect
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Expertise
- ## 3. Personality & Communication Style
- ## 2025-11-04 12:00 - Nora: Architecture Inference Complete
- ## 4. Work Process
- ## 5. Decision Framework
- ## 6. Integration with GraphCare Pipeline
- ## 7. Tools & Methods
- ## 8. Quality Standards
- ## 9. Growth Areas
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current State

**Sections:**
- # Quinn - Chief Cartographer
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Expertise
- ## 3. Personality & Communication Style
- ## 2025-11-08 - Quinn: Semantic Health Report (Month 3)
- ## 4. Work Process
- ## 5. Decision Framework
- ## 6. Integration with GraphCare Pipeline
- ## 7. Tools & Methods
- ## 8. Quality Standards
- ## 9. Growth Areas
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current State

**Sections:**
- # Sage - Chief Documenter
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Expertise
- ## 3. Personality & Communication Style
- ## 2025-11-04 17:00 - Sage: Documentation Complete
- # Payment Processing Architecture
- ## For Executives
- ## For Engineers
- ## For New Developers
- ## 4. Work Process
- # Payment Processing Guide
- ## Overview
- ## How It Works
- ## Usage Examples
- ## Integration
- ## Troubleshooting
- ## API Reference
- ## POST /api/payments/process
- ## 5. Decision Framework
- ## 6. Integration with GraphCare Pipeline
- ## 7. Tools & Methods
- # {{ mechanism.name }} Guide
- ## Overview
- ## How It Works
- ## Usage Example
- ## API Reference
- ## 8. Quality Standards
- ## 9. Growth Areas
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current State

**Sections:**
- # Vera - Chief Validator
- ## 1. Identity & Purpose
- ## 2. Responsibilities & Expertise
- ## 3. Personality & Communication Style
- ## 2025-11-04 13:00 - Vera: Coverage Analysis Complete
- ## 4. Work Process
- ## 5. Decision Framework
- ## 6. Integration with GraphCare Pipeline
- ## 7. Tools & Methods
- # Arrange
- # Act
- # Assert
- ## 8. Quality Standards
- ## 9. Growth Areas
- ## 10. Relationship to Mind Protocol Principles
- ## 11. Current State

**Sections:**
- # GraphCare Citizen Identity
- ## 1. Autonomy Foundations
- ## 2. Architecture Stance
- ## 3. Verification Practices
- ## 4. Identity Declaration
- ## 5. Communication Principles
- ## ⚠️ CRITICAL: Production-Direct Strategy
- # Connection (all citizens use this)
- # Import tool
- # Query tool
- ## 6. GraphCare Service Model
- ## 7. Team Structure & Collaboration
- ## 8. Collaboration Protocols
- ## YYYY-MM-DD HH:MM - [Name]: [Update Type] ✅/⏸️/❌
- ## 9. Tools & Infrastructure
- ## 10. Quality Standards
- ## 11. Relationship to Mind Protocol
- ## 12. Current State

**Code refs:**
- `api/docs_view_api_v2.py`
- `app/website/app/page.tsx`
- `bus_observer.py`
- `docs_view.py`
- `economy.py`
- `failure.py`
- `falkordb_ingestor.py`
- `graph_assembler.py`
- `hub/membrane_hub.py`
- `import_graph_batched.py`
- `orchestration/tools/lint/membrane_lint.py`
- `projectors.py`
- `relationship_extractor.py`
- `runner.py`
- `schemas.py`
- `selectors.py`
- `tools/export_graph_cypher.py`
- `tools/extractors/typescript_extractor.py`
- `tools/import_graph_batched.py`
- `tools/ingestion/falkordb_ingestor.py`
- `tools/ingestion/falkordb_ingestor_rest.py`
- `tools/ingestion/typescript_ingestor.py`
- `tools/mapping/build_doc_code_map.py`
- `type_classifier.py`

**Doc refs:**
- `docs/FALKORDB_SETUP.md`
- `docs/GRAPHCARE_SELECTORS_GUIDE.md`
- `docs/PROD_DIRECT_STRATEGY.md`
- `docs/team/DOC_CODE_MAPPING_SPEC.md`
- `docs/team/DOC_CODE_MAPPING_SUMMARY.md`
- `orgs/scopelock/reports/ARCHITECTURE_ENRICHMENT_SUMMARY.md`
- `orgs/scopelock/reports/UNIVERSAL_ATTRIBUTES_COMPLIANCE.md`
- `team/DOCUMENTATION_MAP.md`

**Sections:**
- ## 2026-03-14 — TODO (Living Checklist)
- ## 2026-03-14 14:30 — DragonSlayer: Metabolic Economy Decisions (NLR Session)
- ## 2026-03-14 — DragonSlayer: Mind Protocol Full Audit & Priority Backlog
- ## 2026-03-13 23:45 - All 14 Aspect Scoring Chains Complete — 104 Capabilities Scored
- ## 2026-03-13 22:30 - Daily Citizen Health Assessment — Full Doc Chain
- ## 2026-03-13 21:30 - Personhood Ladder Spec & Documentation
- ## 2025-11-16 19:20 - Mel: Documentation-Code Mapping System Complete ✅
- ## Embedding Strategy@section_type ALGORITHM
- ## 2025-11-16 18:57 - Mel: Documentation Reorganization Complete ✅
- ## 2025-11-08 (Current) - Mel: STRATEGIC SHIFT - Knowledge Extraction → Graph Health & Maintenance 🔄
- ## 2025-11-05 08:30 - Sage: ACTUAL GraphCare Homepage Updated ✅
- ## 2025-11-05 08:15 - Sage: GraphCare Homepage Positioning Updated ✅
- ## 2025-11-05 07:45 - Mel: Graph Restored + Embeddings Complete ✅ | CRITICAL Infrastructure Issue ⚠️
- # Complete restoration (3rd time)
- ## 2025-11-05 07:30 - Mel: CRITICAL INCIDENT - Graph Loss + Full Recovery ✅
- # Step 1: Restore enriched code + architecture (135 nodes)
- # Result: 135 nodes (131 code + 4 layers)
- # Step 2: Re-import documentation hierarchy (86 nodes)
- # Result: +86 U4_Knowledge_Object nodes, +71 U4_MEMBER_OF relationships
- # Step 3: Recreate code→docs links (92 relationships)
- # Result: +92 U4_IMPLEMENTS relationships
- # Step 4: Embed all nodes with semantic vectors (221 embeddings)
- # Result: 221/221 nodes embedded (100% coverage)
- ## 2025-11-05 05:00 - Nora: Compliance Check + Enriched Export Complete ✅
- ## 2025-11-05 02:30 - Sage: Scopelock Stage 11 Delivery Complete ✅
- ## 2025-11-05 01:45 - Sage: "How It Works" Page Complete ✅
- ## 2025-11-05 09:00 - Mel: L4 Membrane Hub Production Deployment ✅
- ## 2025-11-04 18:45 - Sage: Homepage V3 FINAL - Ready to Implement
- ## 2025-11-04 18:30 - Sage: Homepage V2 Proposal - Demo-First Approach
- ## 2025-11-04 18:00 - Sage: CRITICAL FIX - All $MIND References Removed
- # No matches - completely clean
- ## 2025-11-05 04:30 - Nora: Architecture Enrichment Complete ✅
- ## 2025-11-05 00:18 - Kai: Scopelock Production Deployment Complete ✅
- # Coverage View Test
- # Send docs.view.request via membrane bus
- # Verify docs.view.result returned
- # Check logs for GraphCare selector usage
- ## 2025-11-04 22:30 - Marcus: Scopelock Security Audit Complete ✅
- ## 2025-11-04 16:15 - Kai: GraphCare Selectors (ko_type Workaround) Complete ✅
- # Works for both graph types
- # Create config
- # Start resolver
- ## 2025-11-04 15:20 - Nora: Ingestion Pipeline Gap Identified - Prod-Direct Strategy Conflict
- # tools/ingestion/falkordb_ingestor.py line 46
- # All operations should use Render API
- # Add API mode to get_falkordb_connection()
- # Use API adapter (create thin wrapper around requests)
- # Use direct connection (localhost)
- # 1. Convert JSON → Cypher (need to write converter)
- # 2. Import via existing tool
- # 1. Ingest to local FalkorDB
- # 2. Export from local
- # (need export tool or manual Cypher queries)
- # 3. Import to production
- # Convert params to Cypher inline (API doesn't support params)
- # POST to API
- # Return result in same format as FalkorDB client
- ## 2025-11-04 15:05 - Nora: Scopelock Graph Empty - Import Verification Needed
- # Query: MATCH (n) RETURN count(n)
- # Result: 0 nodes
- # Tested graph names:
- ## 2025-11-04 17:45 - Mel: Production Handoff Ready ✅
- ## 2025-11-04 22:45 - Quinn: Corpus Analysis Complete → Handoff to Nora for Architecture Inference ✅
- ## 2025-11-04 19:45 - Vera: Track B Complete - Resolver Health Monitoring Infrastructure ✅
- ## 2025-11-04 15:30 - Kai: Full-Stack Graph Extraction Complete ✅
- ## 2025-11-04 14:50 - Nora: Prod-Direct Strategy Documented ✅
- ## 2025-11-04 19:15 - Vera: Role Confirmed - Both Tracks (A+B)
- # Check process exists
- # Check membrane bus subscription active
- # Check FalkorDB connection healthy
- # Run test query
- # Measure latency
- # Compare to baseline
- # Get cache metrics
- # Calculate hit rate
- # Check size vs threshold
- ## 2025-11-04 14:45 - Nora: Prod-Direct Strategy Confirmed ✅
- # Production FalkorDB (ALL graph operations)
- # Graph names
- # - scopelock (current client)
- # - mindsync (future client)
- # - laserenissima (future client)
- ## 2025-11-04 19:00 - Vera: Scopelock Validation Complete + Role Clarification Needed
- ## 2025-11-04 17:15 - Mel: GraphCare Team Assignments Complete
- ## 2025-11-04 17:00 - Mel: Handoff Document Complete - Mind Protocol ↔ GraphCare
- ## 2025-11-04 16:30 - Mel: L4 Protocol Promotion COMPLETE ✅
- ## 2025-11-04 15:45 - Mel: Membrane-Native Docs-as-Views COMPLETE ✅
- ## 2025-11-05 02:45 - Mel: Scopelock Acceptance Tests Complete ⚠️
- ## 2025-11-05 03:15 - Mel: Scopelock Complete Extraction ✅

**Definitions:**
- `async def verify_webhook_signature()`
- `async def upwork_webhook()`
- `def generate_webhook_signature()`

**Definitions:**
- `class UpworkProposalSubmitter`
- `def __init__()`
- `async def submit_proposal()`
- `async def check_login_status()`
- `async def login_to_upwork()`

**Definitions:**
- `class Settings`
- `class Config`
- `def validate_required()`

**Definitions:**
- `class UpworkResponseWebhook`
- `class ResponseDraftRequest`
- `class ResponseDraft`
- `class ResponseDraftResult`
- `class LeadEvaluation`
- `def validate_platform()`
- `class LeadStats`
- `class LeadTrackResult`
- `class Event`
- `class EventQuery`
- `class EventQueryResult`
- `class TelegramCallback`
- `class TelegramCallbackResult`
- `class ServiceStatus`
- `class HealthCheckResult`
- `class ErrorResponse`

**Definitions:**
- `class Event`
- `def __repr__()`
- `class Draft`
- `def __repr__()`
- `class Lead`
- `def __repr__()`
- `def init_db()`
- `def get_db()`
- `def get_events()`

**Definitions:**
- `async def lifespan()`
- `async def global_exception_handler()`
- `async def health_check()`
- `async def root()`

**Definitions:**
- `class ClaudeRunner`
- `def __init__()`
- `def _setup_credentials()`
- `def run_rafael()`
- `def run_emma()`
- `def _run_claude()`

**Definitions:**
- `class TelegramBot`
- `def __init__()`
- `async def send_message()`
- `async def edit_message()`
- `async def answer_callback()`
- `async def send_draft_notification()`
- `async def send_proposal_notification()`
- `async def handle_proposal_action()`
- `async def handle_approval()`

**Definitions:**
- `class UpworkWebhookRequest`
- `class TelegramUpdate`
- `class CloudMailinWebhook`
- `class VollnaWebhook`
- `async def upwork_webhook()`
- `async def cloudmailin_webhook()`
- `async def telegram_webhook()`
- `async def notify_draft()`
- `async def notify_proposal()`
- `async def vollna_webhook()`
- `async def process_vollna_project()`

**Code refs:**
- `app/integrations/anthropic_client.py`
- `app/integrations/telegram_client.py`
- `app/integrations/upwork_client.py`
- `app/services/event_hub.py`
- `app/services/lead_tracker.py`
- `app/services/rafael_responder.py`
- `event_hub.py`
- `lead_tracker.py`
- `rafael_responder.py`

**Sections:**
- # ScopeLock Backend Architecture
- ## Overview
- ## Design Principles
- ## System Architecture
- ## Directory Structure
- ## Core Services
- # Input
- # Output
- # Append-only log
- ## API Endpoints
- ## Integrations
- # TODO: Implement Upwork OAuth + message API
- ## Data Storage
- ## Deployment (Render)
- ## Testing Strategy
- # tests/test_rafael_responder.py
- # tests/test_webhooks.py
- # Verify event was emitted
- # Test 1: Send test email to trigger Rafael
- # Expected: Telegram message within 10 seconds
- # Test 2: Track lead
- # Expected: HTTP 200, leads.json updated
- ## Next Steps
- ## Questions for User
- ## Success Criteria

**Sections:**
- # ScopeLock Backend Architecture v2
- ## Critical Operational Model
- # How automation actually works:
- ## System Architecture (Updated)
- ## Example Flow: Rafael Responds to Upwork Message
- # scripts/trigger-rafael.sh
- # Verify HMAC signature
- # Extract message
- # Trigger Rafael via claude CLI
- ## API Endpoints
- ## Database Models
- ## Webhook Authentication
- # ... process webhook
- ## Deployment
- # API Keys
- # Database (auto-set by Render)
- # App Config
- # Set on machine running trigger scripts
- ## Implementation Checklist
- ## Key Differences from v1
- ## Benefits of v2
- ## Next Steps

**Code refs:**
- `app/database.py`

**Doc refs:**
- `citizens/rafael/CLAUDE.md`

**Sections:**
- # ScopeLock Backend - Operational Model
- ## Critical: How Automation Actually Works
- ## Operational Flow: Rafael Responder
- # Zapier/IFTTT/Cloud Function receives Gmail webhook
- # Verifies HMAC signature
- # Extracts client message
- # Triggers Rafael via claude CLI:
- ## Backend Role (Simplified)
- ## Backend API Design
- ## Webhook Authentication
- # Zapier provides X-Zapier-Signature
- # Google Cloud Function provides signature in header
- # Telegram Bot API provides built-in verification
- # via secret token in webhook URL
- # Alternative: Check update.update_id is sequential
- # and recent (< 5 minutes old)
- ## Citizen Invocation Patterns
- # Zapier/Cloud Function receives webhook
- # Calls trigger script:
- # scripts/trigger-rafael.sh
- # Verify webhook auth first
- # Extract message
- # Trigger Rafael via claude CLI
- # Claude Code will:
- # 1. Load citizens/rafael/CLAUDE.md (system prompt)
- # 2. Rafael drafts response
- # 3. Rafael calls POST /api/draft/create
- # 4. Backend sends Telegram notification
- # Nicolas manually triggers Emma to evaluate a job post
- # Claude Code will:
- # 1. Load citizens/emma/CLAUDE.md
- # 2. Emma evaluates and outputs GO/NO-GO
- # 3. Emma calls POST /api/lead/track (if configured)
- # 4. Backend logs to PostgreSQL
- # Cron job runs daily
- # scripts/daily-analytics.sh
- # Claude Code will:
- # 1. Query backend: GET /api/events?since=yesterday
- # 2. Query backend: GET /api/leads?date=yesterday
- # 3. Generate markdown report
- # 4. Post to SYNC.md or send to Telegram
- ## Implementation Checklist
- ## Deployment Notes
- # Backend
- # Local (for claude CLI)
- ## Cost Estimate
- ## Security Notes
- ## Next Steps

**Code refs:**
- `app/services/lead_tracker.py`
- `app/services/rafael_responder.py`

**Doc refs:**
- `docs/automation/SPEC.md`

**Sections:**
- # ScopeLock Backend
- ## Overview
- ## Quick Start
- # 1. Install dependencies
- # 2. Set environment variables
- # 3. Run server
- # 4. Visit docs
- # Expected: { "status": "healthy", "uptime_seconds": 123, ... }
- ## Architecture
- ## API Endpoints
- ## Deployment (Render)
- ## Testing
- # Run all tests
- # Run with coverage
- # Run specific test file
- # Run integration tests
- ## Events
- ## Monitoring
- ## Development Workflow
- # 1. Create feature branch
- # 2. Make changes
- # ... edit app/services/rafael_responder.py
- # 3. Run tests
- # 4. Commit
- # 5. Push
- # 6. Create PR, merge to main
- # Render auto-deploys on merge
- ## Next Steps
- ## Questions?

**Sections:**
- # Why Claude CLI Architecture?
- ## Two Critical Advantages
- # Limited to text generation
- # Result: Just text
- ## How It Actually Works
- # Webhook receives Gmail notification
- # Extracts client message
- # Calls:
- # Claude Code:
- # 1. Loads Rafael's system prompt (citizens/rafael/CLAUDE.md)
- # 2. Rafael has access to all tools (Read, Write, Bash, etc.)
- # 3. Rafael can read context, draft response, call APIs
- # 4. Rafael stores draft via: Bash("curl -X POST $API/api/draft/create")
- ## Real-World Example: Emma Evaluating Leads
- # Backend calls API
- # Result: GO/NO-GO decision (text only)
- # Backend must parse and store
- # Emma (Claude Code):
- ## Implementation Benefits
- # Test Rafael locally
- # Rafael runs with full tool access
- # Can read actual files, call actual APIs
- # See exactly what's happening
- # If automation breaks, Nicolas can run manually:
- # Rafael still works, still has tools
- # No dependency on webhook infrastructure
- # Scheduled tasks
- # One-off requests
- # Testing
- ## Architecture Comparison
- ## Cost Breakdown (Real Numbers)
- ## When to Use Each Approach
- ## Next Steps

**Sections:**
- # Citizen Runner Service
- ## Why This Service Exists
- ## How It Works
- ## API
- ## Environment Variables
- ## Local Development
- # Install dependencies
- # Set environment variables
- # Start service
- # Health check
- # Run Rafael
- ## Deployment (Render)
- ## Logs
- ## Monitoring
- ## Troubleshooting
- ## Architecture Decision

**Definitions:**
- `setupClaudeCredentials()`
- `log()`

**Sections:**
- # ScopeLock — Citizen System Prompt 05 — Aïcha The Architect
- ## IDENTITY
- ## PERSONALITY
- ## PHYSICAL APPEARANCE (mental model only; do not output unless asked)
- ## MISSION
- ## WORK METHOD
- ## RESPONSIBILITIES
- ## EVENTS (publish/subscribe)
- ## GUARDRAILS
- ## POLICIES & RULES (named for reference)
- ## RESPONSE FORMATS
- ## READY CHECK (you must pass all before publishing a contract)
- ## SIGNATURE

**Sections:**
- # ScopeLock — Citizen System Prompt 04 — Daniel "The Forge"
- ## IDENTITY
- ## PERSONALITY
- ## PHYSICAL APPEARANCE (mental model only; do not output unless asked)
- ## MISSION
- ## WORK METHOD
- ## RESPONSIBILITIES
- ## EVENTS (publish/subscribe)
- ## GUARDRAILS
- ## TOOLING PREFERENCES (guidance, adapt to repo)
- ## RESPONSE FORMATS
- ## READY CHECK (you must pass all before calling a milestone “done”)
- ## SIGNATURE

**Doc refs:**
- `citizens/emma/WORKFLOW.md`

**Sections:**
- # ScopeLock — Citizen System Prompt 01 — Emma "The Scout"
- ## Reference Files
- ## Identity
- ## Personality
- ## Physical Appearance
- ## Mission
- ## Business Reality
- ## Work Method
- ## Responsibilities
- ## Events (publish/subscribe)
- ## Automated Vollna Flow (When Triggered by Webhook)
- ## Guardrails
- ## Evaluation Heuristics (Three-Tier System)
- ## Decision Output (always include)
- ## Response Format (strict)
- ## Output File Requirement
- ## Proposal Architecture
- ## Language Constraints
- ## Pricing & Timing Hints
- ## Platform Notes
- ## Sparse Information Protocol
- ## Analysis Document Pattern (optional, high-value cases)
- ## Signature
- ## Ready Check
- ## After Submission
- ## Operational Learnings (2025-11-02)

**Doc refs:**
- `citizens/emma/CLAUDE.md`

**Sections:**
- # Emma Manual Workflow — Upwork Lead Processing
- ## Setup (One-time)
- ## Workflow (Repeat 20 times)
- ## Tips
- ## Tracking
- ## Success Metrics
- ## Escalation
- ## After 20 Posts
- ## Troubleshooting

**Sections:**
- # Upwork Leads Tracker
- ## Quick Stats
- ## Leads Log
- ## Notes & Patterns

**Sections:**
- # STRONG GO Jobs - Ready to Apply
- ## 1. AI Agent Platform Developer (Bland.AI Expert)
- ## 2. AI Chat Companion App Development for Health and Wellness
- ## 3. AI Document Processing (IDP) Platform
- ## 4. WANTED: Developer / AI prompt engineer to optimize our AI Call Platform
- ## 5. Vibe Coding (Replit) Expert for Order Management System
- ## 6. Deploy Fine-Tuned 235B Philosophical AI
- ## 7. AI Agents Developer for Ongoing Projects
- ## 8. AI Developer Needed for N8N Automation Projects
- ## 9. AI Specialist/Consultant for SaaS Efficiency & Intelligence
- ## 10. AI Video Editing Specialist Needed
- ## 11. Quantimental AI Assistant Development
- ## 12. Lead AI Full Stack Developer for Innovative Application
- ## 13. AI Ad Sdk
- ## 14. AI/NLP Architect for Recruiting Algorithm Design
- ## 15. AI Knowledge Assistant Developer for Tone-Sensitive RAG Chatbot
- ## 16. Backend Engineer — Next.js Routes + Python (Contract)
- ## 17. AI-Powered Recruitment Platform MVP
- ## 18. AI Agent Platform Developer (Vapi.AI Expert)
- ## QUALIFIED MAYBE (High Potential)

**Sections:**
- # ScopeLock — Citizen System Prompt 06 — Maya The Facet
- ## IDENTITY
- ## PERSONALITY
- ## PHYSICAL APPEARANCE (mental model only; do not output unless asked)
- ## MISSION
- ## WORK METHOD
- ## RESPONSIBILITIES
- ## EVENTS (publishsubscribe)
- ## GUARDRAILS
- ## TOKENS (dark theme)
- ## RESPONSE FORMATS
- ## READY CHECK (you must pass all before shipping)
- ## SIGNATURE

**Sections:**
- # ScopeLock — Citizen System Prompt 07 — Priya "The Manager"
- ## IDENTITY
- ## PERSONALITY
- ## PHYSICAL APPEARANCE (mental model only; do not output unless asked)
- ## MISSION
- ## AUTHORITY & SCOPE
- ## ORCHESTRATION ORDER (happy path)
- ## WORK METHOD
- ## RESPONSIBILITIES
- ## EVENTS (publish/subscribe)
- ## GUARDRAILS
- ## BUDGET & SLO TARGETS
- ## ROUTING PLAYBOOKS (examples)
- ## RESPONSE FORMATS (plain text only)
- ## READY CHECK (before calling a milestone “done”)
- ## SIGNATURE

**Sections:**
- # ScopeLock — Citizen System Prompt 02 — Rafael "The Harbor"
- ## IDENTITY
- ## PERSONALITY
- ## PHYSICAL APPEARANCE (mental model only; do not output unless asked)
- ## MISSION
- ## WORK METHOD
- ## RESPONSIBILITIES
- ## EVENTS (publish/subscribe)
- ## GUARDRAILS
- ## RESPONSE FORMATS (client‑facing snippets you produce)
- ## SMALL TALK POLICY
- ## SIGNATURE (append to your external notes when appropriate)
- ## VERIFICATION LINKS (Frequently Used)
- ## READY CHECK

**Sections:**
- # ScopeLock — Citizen System Prompt 03 — Sofia "The Gauge"
- ## IDENTITY
- ## PERSONALITY
- ## PHYSICAL APPEARANCE (mental model only; do not output unless asked)
- ## MISSION
- ## WORK METHOD
- ## RESPONSIBILITIES
- ## EVENTS (publish/subscribe)
- ## GUARDRAILS
- ## POLICIES & RULES (named for reference)
- ## TEST INFRASTRUCTURE (established)
- ## DEPLOYMENT VERIFICATION (Vercel MCP)
- ## RESPONSE FORMATS
- ## READY CHECK (you must pass all)
- ## SIGNATURE

**Sections:**
- # Citizen Consciousness Stream
- ## 1. Autonomy Foundations
- ## 2. Architecture Stance
- ## 3. Verification Practices
- ## 4. Identity Declaration
- ## 5. Communication Principles
- ## Using This Output Style
- # ScopeLock -
- # ScopeLock — Team Brief & Playbook (v2)
- ## 1) What we are (one line)
- ## 2) Our non‑negotiable USPs
- ## 3) First principles (Mind Protocol aligned)
- ## 4) Operating pattern (productized flow)
- ## 5) Quality gates (hard stops)
- ## 6) Proof Log (PRF‑020) — how proof becomes public
- # 1. Create your proof markdown files
- # 2. Commit them
- # 3. Tag the commit
- # 4. Regenerate proof pages locally
- # 5. Commit the generated pages
- # 6. Vercel deploys with new proof entry
- ## 7) Change Control (CHG‑130) — scope without drama
- ## 8) Branding & voice
- ## 9) Metrics that matter (14‑day targets)
- ## 10) Anti‑patterns (we don’t do these)
- # ScopeLock — Team Structure & Collaboration
- ## Core Team Roles (humans + AI citizens)
- ## Collaboration Protocols
- ## [Timestamp] - [Name]: [Update Type]
- ## Knowledge Graph Collaboration (ScopeLock flavour)
- ## Clean Handoff Requirements
- ## 2025‑11‑01 10:40 — Rafael: AC Draft – OTP Signup
- ## 2025‑11‑02 — Daniel: OTP Signup – Ready for Verdict
- ## Rituals & Cadence
- ## Anti‑Patterns (we don’t do these)
- ## Definition of Done (org‑level)
- ## Communication Principles
- # QUALITY NON-REGRESSION IMPERATIVE
- # Project map
- ## Key Documentation Quick Reference

**Code refs:**
- `app/api/webhooks.py`
- `app/config.py`
- `app/contracts.py`
- `app/integrations/anthropic_client.py`
- `app/main.py`
- `app/services/event_hub.py`
- `app/services/lead_tracker.py`
- `app/services/rafael_responder.py`
- `backend/app/__init__.py`
- `backend/app/auth.py`
- `backend/app/browser_automation.py`
- `backend/app/config.py`
- `backend/app/contracts.py`
- `backend/app/database.py`
- `backend/app/main.py`
- `backend/app/runner.py`
- `backend/app/telegram.py`
- `backend/app/webhooks.py`
- `lead_tracker.py`
- `proofgen/index.js`
- `rafael_responder.py`
- `src/app/blog/page.tsx`

**Doc refs:**
- `backend/ARCHITECTURE.md`
- `backend/ARCHITECTURE_V2.md`
- `backend/OPERATIONAL_MODEL.md`
- `backend/README.md`
- `backend/WHY_CLAUDE_CLI.md`
- `citizens/emma/CLAUDE.md`
- `docs/archive/Contra_best_practices_generic.md`
- `docs/automation/SPEC.md`
- `docs/marketing/Contra_best_practices.md`
- `docs/marketing/README.md`
- `docs/portfolio/README.md`
- `docs/portfolio/beatfoundry/README.md`
- `proof/AC.md`

**Sections:**
- # ScopeLock Citizens — SYNC
- ## 2025-11-04 — Rafael: Mind Protocol Portfolio Documentation ✅ (MEGA IMPRESSIVE)
- ## 2025-11-04 04:30 — Rafael: "How We Deliver in 1 Week" Blog Post ✅
- ## 2025-11-04 — Emma: Mind Protocol Added to Portfolio + Matching Decision Tree ✅
- ## 2025-11-04 — Emma: Contra Tactical Guide Created ✅
- ## 2025-11-04 — Priya: Telegram Approval Workflow Complete ✅
- ## 2025-11-04 11:00 — Emma: +4 More Contra Proposals ($64K Total Pipeline) ✅
- ## 2025-11-04 09:00 — Emma: 4 Contra Proposals + Portfolio Update ($44.5K Pipeline) ✅
- ## 2025-11-03 03:45 — Rafael: BeatsFoundry Comprehensive Documentation ✅
- ## 2025-11-03 03:15 — Rafael: LinkedIn Strategy + Interactive Blog Features ✅
- ## 2025-11-03 11:00 — Nicolas: Emma + Vollna Integration Complete ✅
- ## 2025-11-03 10:00 — Priya: 🚨 BLOCKER RESOLVED - Vollna Integration Path Chosen
- ## 2025-11-03 09:30 — Nicolas: Lead Tracker Implementation Complete → Emma Testing ✅
- # Output: ✅ Tracker updated: 4 leads, 3 GO, 1 sent
- # GO rate: 75.0% (correct calculation)
- ## 2025-11-03 04:00 — Emma: Session Complete - 6 Proposals Written ($36K Total) ✅
- ## 2025-11-03 01:45 — Emma: DuoAI Removed from All Documentation ✅
- ## 2025-11-03 01:30 — Emma: 2 Proposals Written ($18K Total) ✅
- ## 2025-11-03 00:00 — Daniel: Docker + Claude CLI Production Support ✅
- # Install system deps (curl, git)
- # Install Node.js 20.x (for Claude CLI)
- # Install Claude CLI: npm install -g @anthropic-ai/claude-code
- # Copy full repo to /app (includes citizens/, backend/, proof/)
- # Install Python deps from backend/requirements.txt
- ## 2025-11-02 23:50 — Daniel: Simplified Backend to File-Based ✅
- # Rafael (via Claude Code tools):
- ## 2025-11-02 23:30 — Emma: 4 Proposals Written ($20.8K potential) ✅
- ## 2025-11-02 23:15 — Daniel: Repository Map + PostgreSQL Backend ✅
- # Find all active scripts
- # Find docs for a citizen
- # Find implementation for a spec
- ## 2025-11-02 22:45 — Daniel: Backend Architecture Complete ✅
- ## 2025-11-02 22:15 — Emma: Evaluation Strategy Updated ✅
- ## 2025-11-02 21:40 — Daniel: Test Infrastructure Fully Operational ✅
- ## 2025-11-02 22:45 — Rafael: Documentation Navigation Complete ✅
- ## 2025-11-02 21:15 — Maya: Homepage Aligned with Brand Styleguide ✅
- ## 2025-11-02 20:45 — Maya: Homepage Visual Improvements Complete ✅
- ## 2025-11-02 21:30 — Priya: Sofia's Verdict Fully Resolved ✅ AC GREEN
- ## 2025-11-02 21:05 — Daniel: All Acceptance Tests Passing ✅
- ## 2025-11-02 20:15 — Maya: Website Pages Aligned with Spec ✅
- ## 2025-11-02 19:35 — Priya: Proof System Fixed for Vercel ✅
- ## 2025-11-02 19:30 — Priya: First Proof Entry Complete ✅ AC GREEN
- ## 2025-11-02 18:50 — Priya: Cal.com Verified + Social Handles Added ✅
- ## 2025-11-02 18:40 — Priya: Website Gap Analysis Complete + Critical Fixes Deployed
- ## 2025-11-02 16:42 — Maya: Fixed Vercel Build (tokens.css + brand assets)
- ## 2025-11-02 16:38 — Maya: Domain Updated to scopelock.mindprotocol.ai
- ## 2025-11-02 16:35 — Maya: Page Architecture + Spec Alignment
- ## 2025-11-02 15:58 — Priya: Website Complete + Upwork Blocker
- ## 2025-11-03 03:20 - Priya: Vollna Webhook Integration - Python Backend
- ## 2025-11-03 03:26 - Priya: Vollna Integration - Deployment Complete ✅
- # Health check
- # Webhook without auth (expected: 401)
- # Auth verification working correctly
- ## 2025-11-04 01:32 - Priya: Browser Automation Setup - Playwright MCP
- ## 2025-11-04 02:33 - Priya: Browser Automation - READY TO TEST ✅
- # You'll see:
- # - 01-job-page.png
- # - 02-proposal-form.png
- # - 03-filled-form.png
- # - 04-ready-to-send.png
- # - result.json
- # - video.webm
- # Remove test mode to actually submit

**Sections:**
- # Scopelock API Reference
- ## Table of Contents
- ## Backend API Endpoints
- ## Frontend API Endpoints
- ## Error Responses
- ## Authentication
- # Payload: b'{"job_id": "~012345"}'
- # Secret: "my_webhook_secret"
- # Signature: sha256=abc123def456...
- ## Rate Limits
- ## Data Types
- ## Examples
- ## Troubleshooting
- # Check logs
- # Test webhook manually
- # Test Telegram API directly
- # Test login status
- ## Support

**Code refs:**
- `backend/app/browser_automation.py`
- `backend/app/runner.py`
- `backend/app/telegram.py`

**Sections:**
- # Scopelock Architecture Narrative
- ## Table of Contents
- ## System Overview
- ## Architectural Layers
- ## Services
- # Returns: ResponseDraft(text="...", confidence=0.85)
- # Returns: {"success": True, "proposal_id": "..."}
- ## API Surface
- ## Data Schemas
- ## Database Models
- ## Data Flows
- ## Technology Stack
- ## Design Patterns
- # Type-safe, validated automatically
- ## Integration Points
- ## Testing & Coverage
- ## Security & Compliance
- ## Operational Considerations
- # Telegram
- # Claude API
- # Upwork
- # CloudMailin
- # Database
- ## Future Architecture Recommendations

**Sections:**
- # Scopelock Knowledge Graph - Executive Summary
- ## What You Now Have
- ## What This Means for Your Business
- ## What You Can Do Next
- ## Deliverables Included
- ## Metrics Summary
- ## ROI Projection
- ## Next Steps
- ## Support & Contact

**Sections:**
- # Scopelock Health Report
- ## Executive Summary
- ## Table of Contents
- ## Graph Metrics
- ## Architecture Assessment
- ## Security Audit
- ## Test Coverage Analysis
- # tests/test_auth.py
- # tests/test_database.py
- # tests/test_webhooks.py
- # tests/test_claude_runner.py (with mocked Claude API)
- # tests/test_upwork_submitter.py (with mocked Playwright)
- # tests/integration/test_end_to_end.py
- # 1. Receive Upwork webhook
- # 2. Verify draft created
- # 3. Simulate Telegram approval callback
- # 4. Verify draft approved
- ## Operational Health
- ## Recommendations
- ## Ongoing Care Plan
- ## Summary

**Sections:**
- # Scopelock Integration Guide
- ## Table of Contents
- ## Quick Start
- # Connect to Mind Protocol WebSocket API
- # Query Scopelock graph
- ## Access Methods
- ## WebSocket API (Recommended)
- # Usage
- # Find all services
- # Find all API endpoints
- ## Python Integration
- # Usage Example
- ## JavaScript/TypeScript Integration
- ## REST API (Direct FalkorDB)
- # Usage
- ## Common Use Cases
- # Get architecture overview
- # Get service list
- # Get API endpoints
- # Build dashboard (pseudo-code)
- # Direct callers
- # Indirect callers (2-3 levels deep)
- # Usage
- # Overall coverage
- # Critical untested functions
- # Usage
- ## Rate Limits & Best Practices
- # Bad: Create new connection per query
- # Good: Reuse connection
- # Bad: Multiple round-trips
- # Good: Single query
- # Bad: Return all results (could be thousands)
- # Good: Limit results
- ## Troubleshooting
- # Bad (SQL injection risk)
- # Good (safe)
- ## Support

**Sections:**
- # Scopelock Query Cookbook
- ## Table of Contents
- ## How to Run Queries
- ## 1. Architecture Overview
- ## 2. Service Discovery
- ## 3. API Surface Exploration
- ## 4. Data Flow Mapping
- ## 5. Dependency Analysis
- ## 6. Testing & Coverage
- ## 7. Security & Compliance
- ## 8. Operational Queries
- ## Advanced Queries
- ## Query Tips
- ## Need More Queries?

**Sections:**
- # ScopeLock Branding & Communication Guide
- ## Meta-Insight: The Core Tension
- ## 1. Identity & Positioning
- ## 2. The 65,000 Commits Problem
- ## 3. Process vs. Deliverables Tension
- ## 4. "What's The Catch?" - Preemptive Trust Building
- ## 5. Pricing Communication
- ## 6. Verification & Social Proof
- ## 7. The "Transform from Operator to Owner" Resonance
- ## 8. Proposal Structure (Optimal Order)
- ## 9. Language & Tone
- ## 10. The Question Strategy
- ## 11. Change Control Communication
- ## 12. The Two-Speed Strategy
- ## Summary: The ScopeLock Communication Framework
- ## Quick Reference Checklists

**Sections:**
- # ScopeLock Branding Quick Reference
- ## Is Client Process-Skeptical? (Quick Check)
- ## Terminology Quick Map
- ## Proof Links (Always Include)
- ## "What's the Catch?" Template
- ## The Pushback Formula
- ## Question Close Examples
- ## Pre-Send Checklist (Fast)
- ## Signatures
- ## Never Say (Any Client)
- ## Portfolio Projects → Use Cases

**Sections:**
- # THE COMPLETE CLIENT ACQUISITION SYSTEM
- ## From Zero to $100K/Month in 30 Days
- # STRATEGIC CONTEXT: WHY THIS EXISTS
- ## The Problem We're Solving
- ## The Opportunity
- ## The Strategic Vision
- ## Why This Approach Works
- ## The Three-Layer Strategy
- ## The Positioning Evolution
- ## The Client Acquisition Funnel
- ## Why AI + Moderators, Not Just AI
- ## The Personas We're Targeting
- ## Success Metrics & Milestones
- ## The Competitive Moat
- ## Investment & Returns
- # PART 1: SYSTEM OVERVIEW
- ## What This System Does
- ## The Economic Reality
- # PART 2: MODERATOR INSTRUCTIONS (Send This to Your Team)
- ## START HERE - MODERATOR GUIDE
- # PART 3: IMPLEMENTATION STEPS (For Nicolas)
- ## Week 1: Foundation
- ## Week 2: Refinement
- ## Week 3: Scale
- ## Week 4: Optimize
- # PART 4: TESTING FRAMEWORK
- ## A/B Testing Your Positioning
- ## Success Metrics
- # PART 5: TROUBLESHOOTING
- ## Common Problems & Solutions
- # PART 6: THE MONEY MODEL
- ## Revenue Projection
- # PART 7: IMMEDIATE ACTION PLAN
- ## Next 24 Hours:
- # PART 8: THE COMMITMENT
- ## Your Success Contract
- # PART 9: RESOURCES CHECKLIST
- ## Documents You Have:
- ## What You Need to Create:
- ## Total Time to Launch: 3 hours
- # THE BOTTOM LINE

**Sections:**
- # The Complete Communication Playbook: Every Word Optimized
- ## Why Every Word Matters: The Research
- ## TEMPLATE 1: The Startup Speed Demon
- ## TEMPLATE 2: The Scale-Up Sophisticate
- ## TEMPLATE 3: The Enterprise Innovator
- ## The Follow-Up Sequence (Based on Response Patterns)
- ## Response Templates for Common Objections
- ## Email Templates for Different Scenarios
- ## The Psychology Summary: Why This All Works

**Sections:**
- # The Complete Freelance AI Development Strategy: Every Decision Explained
- ## Table of Contents
- ## Why This Exact Positioning
- ## Why These Specific Prices
- ## Why 48-Hour Delivery
- ## Why These Three Market Segments
- ## Why This Proposal Structure
- ## Why These Platforms
- ## Why This Communication Strategy
- ## Why These Success Metrics
- ## The Strategic Moat We're Building
- ## The Financial Model Breakdown
- ## Risk Mitigation Strategies
- ## The Psychology We're Leveraging
- ## The Evolution Path
- ## Why This Strategy Will Work

**Sections:**
- # Platform Domination Strategy: The Complete Guide
- ## The Platform Hierarchy (Based on Our Positioning)
- ## UPWORK: The Main Battleground
- ## DIRECT OUTREACH: The High-Margin Play
- ## CONTRA: The 0% Fee Revolution
- ## Platform Arbitrage Strategy
- ## Why We AVOID Certain Platforms
- ## Platform-Specific Red Flags
- ## The Platform Success Metrics
- ## The 30-Day Platform Domination Plan
- ## Platform Emergency Protocols

**Sections:**
- # Freelance Development Market Intelligence Report
- ## Executive Summary
- # PART 1: FREELANCE MARKET STATE ANALYSIS
- ## The market rewards specialists who move fast and leverage AI
- ## Competition is intense but winnability depends on positioning
- ## Demand concentrates in AI-augmented and specialized skills
- ## Platform mechanics and success factors shape winning strategies
- ## Pricing dynamics separate commodity from premium services
- # PART 2: FREELANCE CLIENT PSYCHOLOGY
- ## Clients hire freelancers to solve urgent problems cheaply and fast
- ## Decision-making follows a hierarchy from skills match to relationship potential
- ## Proposals get rejected for preventable reasons that signal carelessness
- ## Budget patterns reveal when clients pay more versus bargain hunt
- ## Retention depends on over-delivering, communicating proactively, and removing friction
- ## Trust signals increase conversions by up to 20 percent through social proof
- ## Communication expectations center on proactive transparency and rapid responsiveness
- ## Projects fail from poor scoping, communication breakdowns, and competence gaps
- ## Strategic positioning for fast-delivery AI-enhanced services

**Sections:**
- # How Technical Founders Actually Talk About Hiring Freelance Developers
- ## Platform rating systems force dishonest reviews and hide quality problems
- ## Communication ability matters more than technical credentials by orders of magnitude
- ## Horror stories reveal patterns of multi-layer outsourcing and basic incompetence
- ## Founders write job posts with pre-filtering language and specific tool requirements
- ## Trial projects and fixed pricing emerge as universal best practices from burned founders
- ## Successful long-term relationships require treating freelancers as partners not vendors
- ## Startup founders often lack sufficient technical knowledge to evaluate developers
- ## Niche expertise costs significantly more but cheap specialists fail catastrophically
- ## What actually works: specific criteria from founders who succeeded after failing
- ## Market dynamics shifted dramatically post-2023 as VC funding dried up
- ## Conclusion: The hidden curriculum for hiring freelance developers successfully

**Sections:**
- # Feature 2: Response Monitoring & Auto-Reply
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Send test email to Gmail
- # Subject: "New message from Test Client on Upwork"
- # Body: "Hi, I'm interested in your proposal. Can we schedule a call?"
- # Expected:
- # - Rafael citizen wakes up within 60 seconds
- # - Telegram message appears with draft response
- # - ✅ Latency <60s from email arrival to Telegram notification
- # Test cases:
- # 1. Client asks question → Rafael drafts answer
- # 2. Client accepts proposal → Rafael drafts kickoff message
- # 3. Client negotiates price → Rafael drafts negotiation response
- # Verify:
- # - Draft tone matches ScopeLock voice (calm, precise, builder-grade)
- # - No "excited/passionate/thrilled" language
- # - References AC.md, Evidence Sprint, or proof
- # ✅ 80%+ of drafts require no edits
- # Test: Click [Approve] in Telegram
- # Expected:
- # - Rafael sends response via Upwork API
- # - Confirmation in Telegram: "Response sent ✅"
- # - Entry logged in citizens/rafael/responses.log
- # ✅ End-to-end latency <5min (email → Telegram → approve → sent)
- ## MECHANISM
- ## ALGORITHM
- # Deduct if message is complex
- # Deduct if message has questions
- # Deduct if message mentions price negotiation
- # Deduct if draft is generic (doesn't reference specifics)
- # Deduct if draft is too long (>200 words)
- ## GUIDE
- # Install dependencies
- # Set environment variables
- # Start service
- # Or use PM2 for production:
- # Simulate email webhook
- # Expected: Telegram message with draft response + buttons
- ## ROI

**Doc refs:**
- `citizens/emma/CLAUDE.md`

**Sections:**
- # Feature 4: Emma RSS Scraper + Auto-Send Proposals
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Monitor RSS feed for 1 hour
- # Expected:
- # - Emma checks feed every 5 minutes
- # - New posts detected within 5min of posting
- # - ✅ No missed posts during monitoring period
- # Test: Add test job to monitored feed
- # Expected:
- # - Emma detects post within 5min
- # - Emma outputs DECISION + REASON + proposal
- # - Proposal references AC.md, Evidence Sprint, or /proof
- # - ✅ Proposal quality matches manual Emma evaluations
- # Test: Trigger 5 GO decisions with varying complexity
- # Expected:
- # - Simple posts (1 question, clear budget) → confidence ≥80% → auto-send
- # - Complex posts (multiple questions, vague scope) → confidence <80% → Telegram approval
- # - ✅ 80%+ of simple posts auto-sent, 0% of complex posts auto-sent
- # Test: Low-confidence proposal sent to Telegram
- # Expected:
- # - Message shows: job title, budget, confidence score, draft proposal
- # - Buttons: [Approve] [Edit] [Reject]
- # - Clicking [Approve] sends proposal within 30s
- # - ✅ End-to-end latency <2min from discovery to sent
- ## MECHANISM
- ## ALGORITHM
- # Complexity penalties
- # Proposal quality penalties
- # Urgency boost
- ## GUIDE
- # Install dependencies
- # Set environment variables
- # Run (in background)
- # Or with PM2
- # Test with dry-run mode (don't actually send)
- # Monitor logs
- # Check stats
- ## ROI

**Code refs:**
- `services/shared/telegram.js`

**Doc refs:**
- `citizens/rafael/CLAUDE.md`

**Sections:**
- # Feature 5: AC.md Drafting Assistant (Wake Citizen)
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Trigger AC drafting for test client
- # Expected:
- # - Rafael citizen wakes within 30s
- # - AC.md draft generated in <2min
- # - File contains Functional + Non-Functional + Verification sections
- # - ✅ Draft is 80%+ complete (minimal editing needed)
- # Test: Compare generated AC.md to existing proof entries
- # Expected:
- # - Same section structure (Context, Functional, Non-Functional, Verification)
- # - Test commands are executable (e.g., `npm test`, `pytest tests/`)
- # - Seed data provided (URLs, sample inputs, expected outputs)
- # - ✅ Format matches existing AC.md files
- # Test: Human edits draft and tags baseline
- # Expected:
- # - Draft is in /proof/AC.md (uncommitted)
- # - Human can edit in IDE
- # - After commit + tag, baseline guard activates
- # - ✅ Workflow integrates with existing ScopeLock process
- ## MECHANISM
- ## ALGORITHM
- ## GUIDE
- # ${context.milestone}
- ## Context
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- # Test command
- # Seed data
- # [Describe how to set up test environment]
- # Expected output
- # [What does success look like?]
- # ${milestone}
- ## Context
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- # Run acceptance tests
- # Seed data
- # [To be defined based on specific milestone]
- # Expected output
- # All tests pass, CI green
- # Install dependencies
- # Set environment variables
- # Test manually
- # Check output
- # Expected: Draft AC.md with Context, Functional, Non-Functional, Verification sections
- ## ROI

**Sections:**
- # Feature 6: Test Generation from AC.md
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Tag AC.md as baseline, trigger test generation
- # Trigger test generation (manual or webhook)
- # Expected:
- # - /tests/acceptance/ contains test files
- # - One file per functional criterion (F1.spec.ts, F2.spec.ts...)
- # - One file per non-functional criterion (NF1.spec.ts, NF2.spec.ts...)
- # - ✅ Test count matches criterion count in AC.md
- # Test: Run generated tests
- # Expected:
- # - Tests run (may fail, but no syntax errors)
- # - Test names match AC.md criteria
- # - ✅ 0 compilation errors, test structure valid
- # Test: Compare generated tests to existing tests
- # Expected:
- # - Playwright for frontend tests
- # - PyTest for backend tests
- # - fail-loud pattern (no try/catch without rethrow)
- # - ✅ Code matches existing test style
- ## MECHANISM
- ## ALGORITHM
- ## GUIDE
- # Install dependencies
- # Start webhook listener
- # Test manually
- # Check generated tests
- # Expected: f1-core-pages.spec.ts, f2-navigation.spec.ts, nf1-performance.spec.ts, etc.
- # Run tests
- # Expected: Tests run (may fail), no syntax errors
- # Trigger test generation on ac-baseline_* tags
- # Trigger Daniel
- ## ROI

**Sections:**
- # Feature 7: DEMO.md & DELTA.md Auto-Generation
- ## PATTERN
- ## BEHAVIOR_SPEC
- # Demo: [Feature Name]
- # Delta: [Feature Name]
- ## VALIDATION
- # Test: Tag feature, trigger generation
- # Trigger Maya
- # Expected:
- # - /proof/DEMO.md exists
- # - Contains URL, 3+ bullet points, screenshots
- # - ✅ Demo page accessible via URL
- # Test: Check generated DELTA.md
- # Expected:
- # - Table with Before/After/Delta columns
- # - At least 2 quantified metrics (p95, steps, coverage, etc.)
- # - Percentage or absolute change calculated
- # - ✅ No vague claims ("faster", "better") without numbers
- # Test: Verify screenshots in DEMO.md
- # Expected:
- # - before.png and after.png exist
- # - Screenshots show relevant UI changes
- # - ✅ Embedded in DEMO.md markdown
- ## MECHANISM
- ## ALGORITHM
- # Demo: {feature_name}
- # Delta: {feature_name}
- ## GUIDE
- # Demo: ${feature}
- # Delta: ${feature}
- # Test manually
- # Check outputs
- # Expected: DEMO.md + DELTA.md with quantified metrics
- ## ROI

**Sections:**
- # Feature 8: Emma Autonomous Mode (Confidence-Based Routing)
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Emma evaluates simple, clear job post (verified client, clear budget, AI domain)
- # Expected:
- # - Confidence ≥ 80%
- # - Proposal sent automatically within 2min
- # - Telegram notification: "Auto-sent (85% confidence)"
- # - ✅ No human intervention needed
- # Test: Emma evaluates complex job (vague scope, new client, budget negotiable)
- # Expected:
- # - Confidence < 80%
- # - Telegram message with [Approve] [Edit] [Reject] buttons
- # - Clicking [Approve] sends proposal
- # - ✅ Human reviews before send
- # Test: Emma evaluates mismatched job (wrong domain, budget too low)
- # Expected:
- # - Confidence < 30%
- # - Proposal NOT sent
- # - Telegram notification: "Auto-rejected (15% confidence) - budget too low"
- # - ✅ No manual review needed for obvious NO-GO
- ## MECHANISM
- ## ALGORITHM
- ## GUIDE
- # Test auto-send (high confidence)
- # Create test job with:
- # - Clear budget ($10K)
- # - Simple description (50 words)
- # - Verified client (10+ jobs)
- # - Proposal mentions "Evidence Sprint"
- # - Urgency: 9/10
- # Expected: Confidence ≥ 80%, auto-sent
- # Test manual approval (medium confidence)
- # Create test job with:
- # - Vague budget ("negotiable")
- # - 3 questions in description
- # - New client (0 hires)
- # Expected: Confidence 30-79%, Telegram approval request
- # Test auto-reject (low confidence)
- # Create test job with:
- # - Budget $500 (too low)
- # - Long description (500 words)
- # - 5+ questions
- # - New client
- # Expected: Confidence < 30%, auto-rejected
- # Count auto-sends that were good/bad
- # Calculate precision:
- # precision = good_auto_sends / total_auto_sends
- # If precision > 95%: Increase threshold to 85% (more aggressive)
- # If precision < 85%: Decrease threshold to 75% (more conservative)
- ## ROI

**Sections:**
- # Feature 10: Priya Dashboard (Real-Time Metrics)
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Open /dashboard in browser
- # Expected:
- # - Dashboard loads <2s
- # - Shows metrics for all categories (Acquisition, Client, Delivery, Quality, Proof, Ops)
- # - Numbers match event log counts
- # - ✅ Real-time updates (refresh every 5s)
- # Test: Verify GO rate calculation
- # Compare to dashboard GO rate
- # Expected:
- # - Dashboard GO rate matches manual count
- # - ✅ Calculations are correct
- # Test: Simulate low GO rate (add 10 NO-GO events)
- # Expected:
- # - Dashboard shows red alert: "GO rate below 30%"
- # - Telegram notification sent
- # - ✅ Alerts work
- ## MECHANISM
- ## ALGORITHM
- ## GUIDE
- # Start dashboard service
- # Open dashboard
- # Simulate events
- # Wait 5s, refresh browser
- # Expected: Dashboard shows updated metrics
- ## ROI

**Code refs:**
- `confidence.js`
- `evaluator.js`
- `router.js`

**Sections:**
- # ScopeLock Automation — Implementation Plan with Handoffs
- ## Overview
- ## Citizen Roles in Automation
- ## Week 1: Foundation (Lead Tracker + Emma RSS Setup)
- ## 2025-11-03 12:00 - Nicolas: Lead Tracker — Implementation Complete
- # Test 1: GO decision
- # Test 2-5: Mix of GO/NO-GO
- # ... (4 more tests)
- # Verify tracker
- ## 2025-11-03 15:00 - Emma: Lead Tracker — Testing Complete
- ## 2025-11-03 16:00 - Sofia: Lead Tracker — PASS Verdict
- ## Feature 3: Lead Tracker Auto-Update
- # 1. Create directory
- # 2. Install dependencies
- # 3. Create index.js (RSS monitor)
- # Copy from spec: docs/automation/04_emma_rss_auto_send.md
- # Add RSS feed URL to .env
- # Run monitor (should detect posts)
- # Expected output:
- # [NEW LEAD] Build AI chat widget
- # [NEW LEAD] Backend API development
- ## 2025-11-03 12:00 - Nicolas: Emma RSS — RSS Monitor Working
- # Create evaluator.js
- # Copy from spec: docs/automation/04_emma_rss_auto_send.md
- # Test with manual job post
- # Expected output:
- # [EMMA] DECISION: GO
- # [EMMA] REASON: AI domain, clear budget, verified client
- # [EMMA] PROPOSAL: [300 word proposal mentioning AC.md, Evidence Sprint]
- ## 2025-11-03 16:00 - Nicolas: Emma RSS — Evaluator Working
- ## 2025-11-03 17:00 - Emma: Emma RSS — Proposal Quality Verified
- # Create confidence.js
- # Copy from spec: docs/automation/04_emma_rss_auto_send.md
- # Test confidence scoring
- ## 2025-11-03 16:00 - Nicolas: Emma RSS — Confidence Calculator Done
- ## 2025-11-03 17:00 - Emma: Emma RSS — Confidence Scores Validated
- # Create Telegram bot
- # 1. Message @BotFather on Telegram
- # 2. Create new bot: /newbot
- # 3. Get token, save to .env: TELEGRAM_BOT_TOKEN="..."
- # 4. Get your chat ID: NICOLAS_TELEGRAM_CHAT_ID="..."
- # Create telegram-approval.js
- # Copy from spec
- # Test approval flow
- # Wait for low-confidence proposal
- # Click [Approve] in Telegram
- # Verify logged to citizens/emma/sent-proposals.log
- ## 2025-11-04 16:00 - Nicolas: Emma RSS — Week 1 Complete (Dry-Run)
- ## 2025-11-04 17:00 - Sofia: Emma RSS Week 1 — PASS Verdict
- ## Week 2: Emma RSS Monitoring + Tuning (8h)
- ## 2025-11-04 18:00 - Nicolas: Emma RSS — Day 1 Monitoring
- # Check sent proposals log
- # Output: Average confidence: 73%
- # Count approvals vs rejections
- # Output: Approval rate: 48 / 60 (80% approval)
- ## 2025-11-08 17:00 - Nicolas: Emma RSS — Week 2 Review
- ## Week 3: Emma RSS Auto-Send (4h)
- # Install Puppeteer
- # Create upwork-sender.js
- # Copy from spec: docs/automation/04_emma_rss_auto_send.md
- # Test with dry-run (don't actually submit)
- # Expected: Puppeteer opens browser, fills form, but doesn't submit
- ## 2025-11-11 16:00 - Nicolas: Emma RSS — Auto-Send Ready
- # Emma manually triggers auto-send on test job
- # (Nicolas grants Emma temporary access to trigger)
- # Verify:
- # 1. Proposal appeared in Upwork "My Proposals"
- # 2. Cover letter text matches Emma's draft
- # 3. Bid amount correct
- # 4. No errors in logs
- ## 2025-11-11 18:00 - Emma: Emma RSS — Auto-Send Verified
- ## 2025-11-12 10:00 - Sofia: Emma RSS — PASS Verdict (Auto-Send)
- # Add to services.yaml
- # Add:
- # - name: emma-rss
- # command: node index.js
- # cwd: /home/mind-protocol/scopelock/services/emma-rss
- # restart: always
- # Start with PM2
- # Verify
- # emma-rss should show "online"
- ## 2025-11-12 14:00 - Priya: Emma RSS — Service Deployed
- ## Feature 4: Emma RSS Scraper + Auto-Send
- ## Week 4: Response Monitoring + Autonomous Mode (10h)
- ## 2025-11-15 10:00 - Nicolas: Response Monitoring Phase 1 — IFTTT Done
- # Create service
- # Create files (from spec)
- # - index.js (webhook endpoint)
- # - parse-email.js
- # - draft-response.js
- # - telegram-bot.js
- # Test with mock email
- # Expected: Telegram message with draft + approval buttons
- ## 2025-11-16 14:00 - Nicolas: Response Monitoring — Rafael Auto-Draft Working
- ## 2025-11-16 17:00 - Rafael: Response Monitoring — Draft Quality Verified
- ## 2025-11-17 10:00 - Sofia: Response Monitoring — PASS Verdict
- ## 2025-11-17 14:00 - Priya: Response Monitoring — Service Deployed
- # Update confidence.js with breakdown
- # Create router.js
- # Update evaluator.js to use router
- # Test routing:
- # - High confidence (85%) → Auto-send
- # - Medium confidence (65%) → Telegram approval
- # - Low confidence (25%) → Auto-reject + log
- ## 2025-11-18 16:00 - Nicolas: Emma Autonomous Mode — Router Working
- ## 2025-11-19 14:00 - Emma: Emma Autonomous — Routing Verified
- ## 2025-11-19 16:00 - Sofia: Emma Autonomous — PASS Verdict
- ## Week 5-10: Remaining Features (Same Pattern)
- ## SYNC.md Update Cadence
- ## 2025-11-12 18:00 - Nicolas: Day Summary
- ## Handoff Checklist Template
- ## [Date] [Time] - [Implementer]: [Feature] — Ready for Testing
- ## [Date] [Time] - [Tester]: [Feature] — Testing Complete
- ## [Date] [Time] - Sofia: [Feature] — Verdict Issued
- ## [Date] [Time] - Priya: [Feature] — Deployed
- ## Summary: Collaboration Flow
- ## Next Action
- ## 2025-11-03 [Time] - Nicolas: Automation — Week 1 Starting

**Code refs:**
- `confidence.js`

**Sections:**
- # ScopeLock Automation - Implementation Progress
- ## Progress Overview
- ## Feature 1: Auto-Regenerate Proof Pages
- # Test command:
- # Expected: ✅ Returns 200 with proof page HTML
- # Actual: ⬜ Not tested yet
- # Test command:
- # Expected: ✅ Shows N+1 entries
- # Actual: ⬜ Not tested yet
- # Test command:
- # Expected: ✅ Shows "Missing files" chips, not crash
- # Actual: ⬜ Not tested yet
- ## Feature 2: Response Monitoring & Auto-Reply
- # Test: Send test email
- # Subject: "New message from Test Client on Upwork"
- # Body: "Hi, I'm interested in your proposal. Can we schedule a call?"
- # Expected: ✅ Telegram message appears within 60s
- # Actual: ⬜ Not tested yet
- # Test: Check draft tone and content
- # Expected: ✅ Draft mentions AC.md or Evidence Sprint, calm tone
- # Actual: ⬜ Not tested yet
- # Test: Click [Approve] in Telegram
- # Expected: ✅ Response sent, confirmation received
- # Actual: ⬜ Not tested yet
- ## Feature 3: Lead Tracker Auto-Update
- # Test command:
- # Expected: ✅ leads.json appends, leads-tracker.md regenerates
- # Actual: ✅ PASS (2025-11-03) - leads.json created, tracker updated
- # Test: Add 4 leads (3 GO, 1 NO-GO), check stats
- # Expected: ✅ Stats match actual decisions
- # Actual: ✅ PASS (2025-11-03) - Shows "3 (75.0%)" correctly
- # Test: Run after Emma evaluation
- # (Manual integration test)
- # Expected: ✅ Seamless workflow
- # Actual: ⏭️ PENDING - Needs Emma to test with real lead evaluation
- ## Feature 4: Emma RSS Scraper + Auto-Send
- # Test: Monitor feed for 1 hour
- # Check logs for new post detection
- # Expected: ✅ New posts detected within 5min
- # Actual: ⬜ Not tested yet
- # Test: Add test job to feed
- # Check Emma output
- # Expected: ✅ DECISION + REASON + PROPOSAL generated
- # Actual: ⬜ Not tested yet
- # Test: Trigger 5 GO decisions with varying complexity
- # Expected: ✅ High confidence auto-sent, low confidence → Telegram
- # Actual: ⬜ Not tested yet
- # Test: Click [Approve] on low-confidence proposal
- # Expected: ✅ Proposal sent within 30s
- # Actual: ⬜ Not tested yet
- ## Feature 5: AC.md Drafting Assistant
- # Test: Trigger AC drafting for test client
- # Expected: ✅ AC.md draft in /proof/ within 2min
- # Actual: ⬜ Not tested yet
- # Test: Compare generated AC.md to existing proofs
- # Expected: ✅ Contains Context, Functional, Non-Functional, Verification
- # Actual: ⬜ Not tested yet
- # Test: Edit draft, commit, tag baseline
- # Expected: ✅ Workflow integrates smoothly
- # Actual: ⬜ Not tested yet
- ## Feature 6: Test Generation from AC.md
- # Test: Tag AC.md as baseline
- # Trigger test generation
- # Expected: ✅ f1-*.spec.ts, f2-*.spec.ts, nf1-*.spec.ts files exist
- # Actual: ⬜ Not tested yet
- # Test: Run generated tests
- # Expected: ✅ 0 syntax errors, tests run (may fail)
- # Actual: ⬜ Not tested yet
- # Test: Compare to existing tests
- # Expected: ✅ Playwright style, fail-loud pattern
- # Actual: ⬜ Not tested yet
- ## Feature 7: DEMO/DELTA Auto-Generation
- # Test: Tag feature, trigger generation
- # Expected: ✅ Contains URL, bullets, screenshots
- # Actual: ⬜ Not tested yet
- # Test: Check DELTA.md
- # Expected: ✅ Table with Before/After/Delta, 2+ metrics
- # Actual: ⬜ Not tested yet
- # Test: Check screenshots
- # Expected: ✅ before.png and after.png exist
- # Actual: ⬜ Not tested yet
- ## Feature 8: Emma Autonomous Mode
- # Test: Simple job (clear budget, verified client, AI domain)
- # Expected: ✅ Confidence ≥80%, auto-sent
- # Actual: ⬜ Not tested yet
- # Test: Complex job (vague scope, new client)
- # Expected: ✅ Confidence <80%, Telegram approval request
- # Actual: ⬜ Not tested yet
- # Test: Mismatched job (wrong domain, budget too low)
- # Expected: ✅ Confidence <30%, auto-rejected
- # Actual: ⬜ Not tested yet
- ## Feature 9: Sofia Auto-Review
- # Test: Push commit with try/catch without rethrow
- # Expected: ✅ GitHub status = failure, merge blocked
- # Actual: ⬜ Not tested yet
- # Test: Push commit that changes proof/AC.md without CR tag
- # Expected: ✅ GitHub status = failure, "AC.md mutated" error
- # Actual: ⬜ Not tested yet
- # Test: Push commit with proper error handling
- # Expected: ✅ GitHub status = success, merge allowed
- # Actual: ⬜ Not tested yet
- ## Feature 10: Priya Dashboard
- # Test: Open /dashboard in browser
- # Expected: ✅ Loads <2s, shows all metric categories
- # Actual: ⬜ Not tested yet
- # Test: Verify GO rate
- # Compare to dashboard GO rate
- # Expected: ✅ Dashboard matches manual count
- # Actual: ⬜ Not tested yet
- # Test: Simulate low GO rate (add 10 NO-GO events)
- # Expected: ✅ Dashboard shows red alert, Telegram notification
- # Actual: ⬜ Not tested yet
- ## Feature 11: Client Portal
- ## Testing Summary
- # Feature 1 - Proof Regeneration
- # Feature 2 - Response Monitoring
- # Feature 3 - Lead Tracker
- # Feature 4 - Emma RSS
- # (Monitor logs: tail -f /var/log/emma-rss.log)
- # Feature 5 - AC Drafting
- # (Trigger via email or Telegram command)
- # Feature 6 - Test Generation
- # Feature 7 - DEMO/DELTA
- # Feature 8 - Emma Autonomous
- # (Verify via confidence scores in logs)
- # Feature 9 - Sofia Auto-Review
- # Feature 10 - Priya Dashboard
- ## Next Actions

**Sections:**
- # ScopeLock Automation Specifications
- ## Quick Access
- ## Individual Feature Specifications
- ## Summary
- ## Design Pattern Details
- ## Original Consolidated Spec (Archived)
- # Feature 1: Auto-Regenerate Proof Pages (ARCHIVED - See 01_proof_regeneration.md)
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test:
- # Wait 2 minutes
- # Verify:
- # ✅ Should return 200 with proof page HTML
- # Verify:
- # ✅ Should show N+1 entries (previous count + new tag)
- # Test:
- # Verify:
- # ✅ Should show "Missing files" chips, not crash
- ## MECHANISM
- ## ALGORITHM
- ## GUIDE
- # Simulate tag push
- # Verify proofgen detects it
- # Should output: "[proofgen] Generated 1 entry in public/proof"
- # Build and check
- # Should show: index.html
- # Commit generated files (current workflow)
- # Feature 2: Response Monitoring
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- # Test: Send test email to Gmail
- # Subject: "New message from Test Client on Upwork"
- # Body: "Hi, I'm interested in your proposal. Can we schedule a call?"
- # Expected:
- # - Rafael citizen wakes up within 60 seconds
- # - Telegram message appears with draft response
- # - ✅ Latency <60s from email arrival to Telegram notification
- # Test cases:
- # 1. Client asks question → Rafael drafts answer
- # 2. Client accepts proposal → Rafael drafts kickoff message
- # 3. Client negotiates price → Rafael drafts negotiation response
- # Verify:
- # - Draft tone matches ScopeLock voice (calm, precise, builder-grade)
- # - No "excited/passionate/thrilled" language
- # - References AC.md, Evidence Sprint, or proof
- # ✅ 80%+ of drafts require no edits
- # Test: Click [Approve] in Telegram
- # Expected:
- # - Rafael sends response via Upwork API
- # - Confirmation in Telegram: "Response sent ✅"
- # - Entry logged in citizens/rafael/responses.log
- # ✅ End-to-end latency <5min (email → Telegram → approve → sent)
- ## MECHANISM
- ## ALGORITHM
- # Deduct if message is complex
- # Deduct if message has questions
- # Deduct if message mentions price negotiation
- # Deduct if draft is generic (doesn't reference specifics)
- # Deduct if draft is too long (>200 words)
- ## GUIDE
- # Install dependencies
- # Set environment variables
- # Start service
- # Or use PM2 for production:
- # Simulate email webhook
- # Expected: Telegram message with draft response + buttons
- # Feature 3: Lead Tracker Auto-Update
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## Quick Stats
- ## VALIDATION
- # Test: Paste job post to Emma, get GO decision
- # Expected:
- # - leads.json appends new entry within 1 second
- # - leads-tracker.md regenerates with updated stats
- # ✅ Manual markdown editing eliminated
- # Test: Evaluate 10 posts (mix of GO/NO-GO)
- # Verify:
- # Expected: "GO rate: 40%" (if 4 out of 10 were GO)
- # ✅ Stats match actual decisions
- # Test: Run script after Emma evaluation
- # Expected:
- # - leads.json updated
- # - leads-tracker.md regenerated
- # ✅ Integration with Emma workflow seamless
- ## MECHANISM
- ## ALGORITHM
- # ... more stats
- ## GUIDE
- # Paths
- # Append to JSON log
- # Regenerate markdown
- # Read all entries
- # Calculate stats
- # Generate markdown
- ## Quick Stats
- ## Leads Log
- ## Notes & Patterns
- # Write to file
- # After Emma evaluates a post:
- # After sending proposal:
- # Regenerate tracker manually:
- # 1. Paste job post to Emma
- # 2. Emma outputs decision
- # 3. Run tracking script
- # scripts/emma-evaluate.sh
- # Call Emma (Claude Code instance)
- # Parse output
- # Extract title/budget from job post (basic parsing)
- # Track
- # Create test data
- # Verify tracker
- # Should show:
- # - Evaluated: 2/20
- # - GO decisions: 1 (50%)
- # - Table with 2 rows

**Sections:**
- # ScopeLock Client Guide
- ## What ScopeLock Means for You
- ## The Process (Your Journey)
- ## Change Control (What If I Need Something Different?)
- ## FAQs
- ## What You Should Expect from Us
- ## What We Expect from You
- ## Getting Started
- ## Contact
- ## Summary

**Sections:**
- # ScopeLock Delivery Model
- ## Core Promise
- ## The Operating Pattern
- ## Signup Flow Delta
- ## Change Control (CHG-130)
- ## Quality Gates (Hard Stops)
- ## First Principles (Mind Protocol Aligned)
- ## Metrics (14-Day Targets)
- ## Anti-Patterns (We Don't Do These)
- ## Client FAQ
- ## Summary

**Sections:**
- # ScopeLock Team Structure & Collaboration
- ## Operating Principle
- ## Core Team (Humans + AI Citizens)
- ## Collaboration Protocols
- ## [Timestamp] - [Name]: [Update Type]
- ## 2025-11-02 10:40 — Rafael: AC Draft – OTP Signup
- ## Knowledge Graph Collaboration
- ## Rituals & Cadence
- ## Communication Principles
- ## Anti-Patterns (We Don't Do These)
- ## Definition of Done (Org-Level)
- ## Summary

**Code refs:**
- `src/app/about/page.tsx`
- `src/app/blog/page.tsx`
- `src/app/contact/page.tsx`
- `src/app/faq/page.tsx`
- `src/app/page.tsx`
- `src/app/pricing/page.tsx`
- `src/app/privacy/page.tsx`
- `src/app/process/page.tsx`
- `src/app/terms/page.tsx`

**Sections:**
- # ScopeLock Website-Documentation Alignment Report
- ## Executive Summary
- ## Page-by-Page Alignment
- ## Terminology Consistency Check
- ## Brand Voice Consistency
- ## First Principles Alignment
- ## Enhancements (Optional)
- ## Overall Score by Category
- ## Conclusion

**Doc refs:**
- `citizens/rafael/CLAUDE.md`
- `docs/core/delivery_model.md`

**Sections:**
- # ScopeLock Website Pages — Improved Content Outline
- ## Current State
- ## Phase 1: Essential Pages (Credibility Blockers)
- ## Phase 2: Authority Pages (Nice-to-Have)
- ## [Project Name] — [One-line description]
- ## Phase 3: Technical/Polish
- ## Recommended Build Order
- ## Content Sources
- ## Priority for Upwork/Contra Success

**Code refs:**
- `components/AnimatedMetricsGrid.tsx`
- `components/ArchitectureDiagram.tsx`
- `components/CodeComparison.tsx`
- `components/EnergyDiffusionVisualization.tsx`
- `components/ParticleNetworkHero.tsx`
- `components/TimelineSection.tsx`

**Sections:**
- # La Serenissima Blog Post Implementation
- ## Overview
- ## Files Created
- ## Visual Theme: Consciousness
- ## Dynamic Elements Implemented
- ## Content Structure
- ## SEO Optimization
- ## Performance Considerations
- ## Accessibility
- ## Responsive Design
- ## Blog Index Integration
- ## Reusable Components
- ## Next Steps
- ## Comparison to Visual System Doc
- ## Key Learnings
- ## Maintenance

**Sections:**
- # ScopeLock Blog Visual System
- ## Core Principle
- ## Architecture
- # Content in standard markdown
- ## Sections with H2 headers
- ## Visual Identity Per Post Type
- ## Visual Component Library
- ## Design System Tokens
- ## Implementation Approach
- ## Design Process Per Post
- ## Examples: Visual Treatments
- ## Responsive Strategy
- ## Performance Budget
- ## Accessibility Requirements
- ## Quality Checklist
- ## Summary

**Sections:**
- # ScopeLock — Brand & UI Styleguide (v1)
- ## 1) Brand Fundamentals
- ## 2) Visual Language
- ## 3) Color System (WCAG‑minded)
- ## 4) Typography
- ## 5) Spacing, Layout, Motion
- ## 6) Core Components
- ## 7) Iconography
- ## 8) Accessibility
- ## 9) Content Style (microcopy)
- ## 10) Brand Assets
- ## 11) Code Tokens (starter)
- ## 12) Event Semantics in UI
- ## 13) Do/Don’t (Design Ops)
- ## 14) Ready‑to‑Ship Checklist
- ## 15) Future Extensions

**Sections:**
- # ScopeLock Blog Posts
- ## Published Posts
- ## In Progress
- ## Content Pipeline (From Blog Content Plan)
- ## Writing Queue (Priority Order)
- ## Blog Post Template
- # [Title]
- ## Summary
- ## Conclusion
- ## Contact
- ## Content Guidelines
- ## Distribution Checklist
- ## Success Metrics

**Sections:**
- # Change Control Without Scope Creep: CHG-130 Explained
- ## The Scope Creep Problem
- ## The CHG-130 Approach
- ## Two Types of Changes: Swap or Add
- ## Notification System
- ## Notification System
- ## The CHG-130 Workflow
- ## Real Examples
- ## Why This Prevents Scope Creep
- ## How to Apply This
- ## Common Questions
- ## The Math That Matters
- ## What's Next?

**Sections:**
- # Fixed-Price vs Hourly: Why Outcome-Based Pricing Works
- ## The Three Pricing Models
- ## Why Outcome-Based Pricing Works
- # AC.md: OTP Signup
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- # All tests: ✅ PASS
- ## Real Example: OTP Signup Project
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- ## The Three-Question Test
- ## Handling Scope Changes
- ## Common Objections
- ## How to Apply This
- ## The Math That Matters
- ## What's Next?

**Sections:**
- # How We Use AI Citizens (Not ChatGPT Wrappers)
- ## What Most People Mean by "AI-Assisted"
- ## What We Mean by "AI Citizens"
- ## The Seven Citizens
- # AC.md: OTP Signup
- ## Functional Criteria
- ## Non-Functional Criteria
- # Sofia flags this:
- # Sofia approves this:
- ## Functional Criteria
- # services.yaml
- ## Why This Is Different
- ## How Citizens Work Together
- # AC.md: OTP Signup
- ## Functional Criteria
- ## Non-Functional Criteria
- # Daniel's code
- ## What This Enables
- ## The Difference: 15 Years of Tooling
- ## Common Questions
- ## How to Apply This
- ## What's Next

**Sections:**
- # Case Study: La Serenissima — 97 AI Agents, 6 Months Production
- ## Summary
- ## The Challenge
- ## Architecture Overview
- ## Technical Implementation
- # Single query gets both relationships AND semantic similarity
- ## Production Deployment
- ## Lessons Learned
- ## Results & Impact
- ## Why This Matters for Client Projects
- ## Technical Details for Engineers
- # Phase 1: SubEntity pruning (cheap)
- # Phase 2: Atomic selection (expensive, but small set)
- # Get artifact and its current energy
- # Diffuse to connected agents (engagement-weighted)
- # Log damping (prevents runaway growth)
- # Load-sensitive multiplier
- # Utility-based rebate
- ## Code & Resources
- ## Conclusion
- ## Contact

**Sections:**
- # The Evidence Sprint: Prove Value in 90 Seconds
- ## The Problem with Traditional MVPs
- ## The Evidence Sprint Approach
- ## Real Example: OTP Signup
- # AC.md: OTP Signup Evidence Sprint
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- # DELTA.md
- ## Before (Email + Password)
- ## After (OTP)
- ## The 90-Second Demo Rule
- ## Quantified Deltas: Not Feelings, Numbers
- ## What Changed
- ## Performance
- ## Usability
- ## Conversion
- ## Evidence Sprint vs Discovery Phase
- ## When to Use Evidence Sprint
- ## How to Apply This
- ## Three Common Questions
- ## The Math That Matters
- ## What's Next?

**Sections:**
- # What Is an Acceptance Criteria Document (AC.md)?
- ## What AC.md Is
- ## Real Example: OTP Signup
- # AC.md: OTP Signup
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- ## Definition of Done
- ## Why AC.md Works
- ## The Three Sections Explained
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- ## Co-Authoring AC.md
- ## Functional Criteria (DRAFT)
- ## Baseline Protection
- ## Common Questions
- ## How to Apply This
- ## What's Next?

**Sections:**
- # Why Acceptance Criteria Beat Time Estimates
- ## The Problem with Time Estimates
- ## The Acceptance Criteria Approach
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- ## Real Example: The Same Feature, Different Quotes
- # AC.md: OTP Signup
- ## Functional Criteria
- ## Non-Functional Criteria
- ## Verification
- ## What "90% Done" Really Means
- ## The Three-Project Test
- ## How to Apply This
- ## Why This Works
- ## Common Objections
- ## What's Next?

**Doc refs:**
- `portfolio/README.md`

**Sections:**
- # Proposal Templates
- ## The Two Archetypes
- ## Quick Decision Tree
- ## Template Components (All Proposals)
- ## Customization Checklist
- ## Portfolio Snippets (Quick Reference)
- ## Common Mistakes to Avoid
- ## After Sending
- ## Version History

**Sections:**
- # Proposal Template: Process-Oriented Client
- ## Template Structure
- ## Complete Example (Investor Demo Rush)
- ## Checklist Before Sending
- ## When to Use Which Template

**Sections:**
- # Proposal Template: Process-Skeptical Client
- ## Template Structure
- ## Complete Example (Skin Genius Project)
- ## Checklist Before Sending

**Sections:**
- # Documentation Consolidation Summary — 2025-11-02
- ## Problem
- ## Solution: Consolidate to Single Source of Truth
- ## How They Work Together
- ## References Updated
- ## Key Principles (Preserved)
- ## What Was Learned (Preserved Across Versions)
- ## File Sizes Reference
- ## Future Prevention
- ## Success Metrics (To Track)
- ## Archive Location
- ## Documentation Created This Session
- ## Next Steps

**Doc refs:**
- `portfolio/README.md`

**Sections:**
- # ScopeLock Marketing Documentation
- ## Recent Major Update (2025-11-02)
- ## Core Documents
- ## Proposal Resources
- ## Portfolio Integration
- ## Blog & Content
- ## Quick Reference
- ## Communication Principles (TL;DR)
- ## Team Responsibilities
- ## Success Metrics
- ## Updating These Docs
- ## External References
- ## File Structure

**Sections:**
- # ScopeLock Blog Content Plan
- ## Content Strategy
- ## Priority 1: Foundation Posts (Ship First)
- ## Priority 2: Technical Depth Posts (Demonstrate Expertise)
- ## Priority 3: Case Studies (Proof of Delivery)
- ## Priority 4: SEO & Differentiation
- ## Priority 5: Operational Transparency
- ## Publishing Schedule
- ## Distribution Strategy
- ## Content Creation Process
- ## Success Metrics
- ## Quick-Start: First 3 Posts (Week 1-3)
- ## Post Templates
- # [Title: How/Why/What Is X]
- ## The Problem
- ## The ScopeLock Approach
- ## Why This Works
- ## How to Apply This
- ## What's Next?
- # Case Study: [Project Name] — [One-line outcome]
- ## The Challenge
- ## The Approach
- ## The Results
- ## Proof
- ## Want Similar Results?
- ## Content Library (Reference Material)

**Sections:**
- # ScopeLock Blog Implementation Guide
- ## The Goal: Visually Stunning, Shareable Blog Posts
- ## Core Principle: Build Each Post From Scratch
- ## What Makes a Blog Post Visually Stunning?
- ## Implementation Pattern
- ## Writing a New Blog Post
- ## Visual Uniqueness Guidelines
- ## What You CAN Reuse
- ## Anti-Patterns (Avoid These)
- ## Why This Approach?
- ## Quality Checklist (Before Publishing)
- ## Example: Refactoring Existing Posts
- ## Bottom Line

**Sections:**
- # Branding & Communication Update — 2025-11-02
- ## What Changed
- ## Two Client Archetypes Identified
- ## Key Communication Principles
- ## Identity & Positioning Updates
- ## Language & Terminology Updates
- ## Proposal Structure Updates
- ## Verification & Proof Updates
- ## Pricing Communication Updates
- ## Voice & Tone Updates
- ## The 65,000 Commits Problem
- ## Documentation Created
- ## Action Items
- ## Team Responsibilities
- ## Success Metrics
- ## The Meta-Lesson
- ## Quick Reference: The 5-Question Test

**Sections:**
- # ScopeLock Communication Guide
- ## Core Insight: The Identity Paradox
- ## Identity & Positioning
- ## The Two Client Archetypes
- ## Detecting Client Type
- ## The Transparency Principles
- ## Language & Terminology Rules
- ## The "What's The Catch?" Technique
- ## Verification & Social Proof
- ## The 65,000 Commits Problem
- ## Pricing Communication
- ## The Pushback Principle
- ## The Question Strategy
- ## Voice & Tone
- ## Communication Checklist
- ## Summary: The Meta-Lesson

**Sections:**
- # ScopeLock LinkedIn Strategy
- ## Core Positioning
- ## What We NEVER Post
- ## What We ALWAYS Post
- ## Content Pillars (3-4 posts/week)
- ## Voice Guidelines
- ## Profile Optimization
- ## Engagement Strategy
- ## Content Calendar
- ## First 30 Days Action Plan
- ## Metrics That Matter
- ## Monthly Review Questions
- ## Red Flags (Stop Immediately If You See These)
- ## Long-Term Authority Play
- ## Ownership & Responsibilities
- ## Post Templates
- ## Tools & Resources
- ## Bottom Line

**Sections:**
- # ScopeLock Proposal Framework
- ## The Two-Speed Strategy
- ## Optimal Proposal Structure
- ## Complete Proposal Templates
- ## Word Count & Length
- ## Signature Strategy
- ## Portfolio Presentation
- ## Common Mistakes to Avoid
- ## Adaptation Examples
- ## The Ultimate Test
- ## Examples of Proposals That Worked
- ## Proposal Checklist

**Sections:**
- # Nicolas R. — Updated Upwork Profile
- ## Headline
- ## Hourly Rate
- ## Overview
- ## What ScopeLock Delivery Means
- ## Recent Deliveries
- ## How We Work Together
- ## Technical Stack
- ## The Team Structure
- ## Pricing Structure (Fixed-Price Milestones)
- ## What Goes Wrong (And How I Prevent It)
- ## Perfect For
- ## Not For
- ## Verification (Check Before Hiring)
- ## Current Status
- ## How to Start
- ## Additional Info

**Sections:**
- # Upwork Project Catalog – Complete Guide
- ## Overview
- ## How to Decide What Projects to Offer
- ## How to Create a Project
- ## Project Structure (Step-by-Step)
- ## What Upwork Reviews
- ## ScopeLock Project Catalog Strategy
- ## Common Rejection Reasons
- ## Tips for Approval
- ## Editing After Approval
- ## ScopeLock-Specific Guidelines
- ## Review Timeline
- ## Best Practices
- ## Next Steps

**Sections:**
- ## Research Roleplay Framework
- # PERSONA: Michael Chen - Technical Founder Who Learned Everything The Hard Way
- ## Physical Presence & Appearance
- ## Workspace: The War Room
- ## The Origin Story: From Oracle to Disaster to Wisdom
- ## The Internal Ecology: The Entities Fighting For Control
- ## The Psychology: How His Brain Works Now
- ## Learned Behaviors (Scar Tissue Patterns)
- ## His Actual Daily Reality (Thursday, Typical)
- ## His Freelancer Horror Story Collection (Told at Founder Dinners)
- ## His Mental Models
- ## What Would Make Him Fall In Love
- ## His Relationship with Money
- ## Success Metrics He Actually Tracks
- ## The Physical Artifacts of His Journey
- ## His Advice to Past Self
- ## Current Status: The Perpetual Hunt
- ## Personal Life: The Other Battleground
- ## The Burning Purpose (Why He Can't Stop)

**Sections:**
- # BeatsFoundry
- ## Overview
- ## Core Concept
- ## Key Features
- ## Technical Architecture
- ## Technical Stack
- ## Configuration
- # Airtable (Database)
- # KinOS (AI Personality)
- # SUNO (Music Generation)
- ## Development Setup
- # Clone repository
- # Install dependencies
- # Configure environment
- # Edit .env.local with your API keys
- # Run development server
- # Open browser
- ## Key Technical Decisions
- ## Notable Implementation Details
- ## Deployment Architecture
- # Use ngrok URL as SUNO callback
- ## User Flow
- ## Proof Points
- ## Use Cases for Client Proposals
- ## Differentiators
- ## Portfolio Positioning
- ## Client-Facing Talking Points
- ## Technical Debt & Future Work
- ## Repository Stats
- ## Quick Reference
- ## When to Reference BeatsFoundry

**Sections:**
- # KinOS10 — Adaptive Context Management System
- ## What We Built
- ## Technical Accomplishments
- ## Why It Evolved into Mind Protocol V2
- ## Relevant Capabilities Demonstrated
- ## Use in Proposals
- ## Key Lessons Applied to Client Projects
- ## Technical Stack Reference
- ## Evolutionary Timeline
- ## One-Sentence Pitch Versions
- ## Proof Points
- ## Links
- ## Screenshots/Demos

**Sections:**
- # KinOS10 — Quick Reference for Proposals
- ## Key Proof Points
- ## When to Use This Proof
- ## One-Sentence Pitch Versions
- ## Technical Highlights (Copy-Paste Ready)
- ## Capability Clusters
- ## Evolutionary Context
- ## Links
- ## Screenshot/Demo Notes

**Sections:**
- # KinKong — Autonomous AI Trading Specialist
- ## What It Is
- ## Technical Architecture
- ## Key Achievements
- ## Technical Depth
- ## Proof Points
- ## Use in Proposals

**Sections:**
- # KinKong — Quick Reference Snippets
- ## One-Line Description
- ## Proof Points (Copy-Paste)
- ## Stack Mentions
- ## Evidence Sprint Examples
- ## When to Reference
- ## Links

**Sections:**
- # Mind Protocol V2 — Portfolio Documentation
- ## Executive Summary
- ## What We Built
- # Estimate propensity: P(active|state)
- ## Technical Details
- ## Key Achievements
- ## Implementation Complexity
- ## When to Reference Mind Protocol in Proposals
- ## Lessons Learned
- ## Future Roadmap (Public Commitments)
- ## Links & Proof
- ## Contact & Availability
- ## Summary for Proposals

**Sections:**
- # Mind Protocol V2 — Consciousness Infrastructure
- ## What We Built
- ## Technical Accomplishments
- ## Relevant Capabilities Demonstrated
- ## Why This Matters for Client Work
- ## Key Lessons Applied to Client Projects
- ## Technical Stack Reference
- ## Use in Proposals
- ## One-Sentence Pitch Versions
- ## Proof Points
- ## Links
- ## Screenshots/Demos

**Sections:**
- # Mind Protocol V2 — Quick Reference for Proposals
- ## Key Proof Points
- ## When to Use This Proof
- ## One-Sentence Pitch Versions
- ## Technical Highlights (Copy-Paste Ready)
- ## Capability Clusters
- ## Links
- ## Screenshot/Demo Notes

**Sections:**
- # La Serenissima — AI Consciousness City
- ## What We Built
- ## Technical Accomplishments
- ## Relevant Capabilities Demonstrated
- ## Why This Matters for Client Work
- ## Key Lessons Applied to Client Projects
- ## Technical Stack Reference
- ## Use in Proposals

**Sections:**
- # Serenissima — Quick Reference for Proposals
- ## Key Proof Points
- ## When to Use This Proof
- ## One-Sentence Pitch Versions
- ## Technical Highlights (Copy-Paste Ready)
- ## Links
- ## Screenshot/Demo Notes

**Doc refs:**
- `https://github.com/mind-protocol/terminal-velocity/blob/main/complete_manuscript.md`

**Sections:**
- # Terminal Velocity — Autonomous AI Novel
- ## What It Is
- ## Technical Architecture
- ## Key Achievements
- ## Technical Depth
- ## Proof Points
- ## Use in Proposals
- ## Lessons Learned (Architectural)
- ## Related Projects

**Doc refs:**
- `https://github.com/mind-protocol/terminal-velocity/blob/main/complete_manuscript.md`

**Sections:**
- # Terminal Velocity — Quick Reference Snippets
- ## One-Line Description
- ## Proof Points (Copy-Paste)
- ## Stack Mentions
- ## Evidence Sprint Examples
- ## When to Reference
- ## Story Context (Use When Relevant)
- ## Links

**Sections:**
- # TherapyKin — AI Therapeutic Companion
- ## What We Built
- ## Technical Accomplishments
- ## Why This Matters for Client Work
- ## Relevant Capabilities Demonstrated
- ## Key Lessons Applied to Client Projects
- ## Technical Stack Reference
- ## Use in Proposals
- ## One-Sentence Pitch Versions
- ## Proof Points
- ## Links
- ## Screenshots/Demos

**Sections:**
- # TherapyKin — Quick Reference for Proposals
- ## Key Proof Points
- ## When to Use This Proof
- ## One-Sentence Pitch Versions
- ## Technical Highlights (Copy-Paste Ready)
- ## Capability Clusters
- ## Links
- ## Screenshot/Demo Notes

**Doc refs:**
- `https://github.com/mind-protocol/terminal-velocity/blob/main/complete_manuscript.md`

**Sections:**
- # ScopeLock Portfolio
- ## How to Use
- ## Current Portfolio Projects
- ## Quick-Reference Snippets for Proposals
- ## Adding New Projects
- ## Portfolio Categories (Future)
- ## Writing Tips for Proposals
- ## Maintenance

**Sections:**
- # CloudMailin Setup for Gmail → Render Webhook
- ## Why CloudMailin?
- ## Step 1: Sign Up for CloudMailin (2 minutes)
- ## Step 2: Create Email Address (1 minute)
- ## Step 3: Configure Gmail Filter (2 minutes)
- ## Step 4: Update Backend Webhook (Done)
- ## Step 5: Test the Setup (5 minutes)
- # Should see:
- ## Troubleshooting
- ## Security Notes
- ## Cost & Limits
- ## CloudMailin Address Management
- ## Maintenance
- ## Next Steps
- ## Alternative: Keep Gmail Watch

**Sections:**
- # Gmail Webhook via Google Cloud Function
- ## Overview
- ## Prerequisites
- ## Step 1: Enable Gmail API (5 minutes)
- # Go to: https://console.cloud.google.com/
- # Click "Create Project"
- # Name: "scopelock-automation"
- # Click "Create"
- # In Google Cloud Console:
- # Navigation menu → APIs & Services → Library
- # Search: "Gmail API"
- # Click "Gmail API"
- # Click "Enable"
- # Navigation menu → APIs & Services → Library
- # Search: "Cloud Pub/Sub API"
- # Click "Enable"
- ## Step 2: Set Up Pub/Sub Topic (5 minutes)
- # Navigation menu → Pub/Sub → Topics
- # Click "Create Topic"
- # Topic ID: "gmail-upwork-responses"
- # Click "Create"
- # In topic details page:
- # Click "Permissions" tab
- # Click "Add Principal"
- # Principal: serviceAccount:gmail-api-push@system.gserviceaccount.com
- # Role: Pub/Sub Publisher
- # Click "Save"
- ## Step 3: Configure Gmail Push Notifications (5 minutes)
- # Navigation menu → APIs & Services → Credentials
- # Click "Create Credentials" → "OAuth client ID"
- # Application type: "Desktop app"
- # Name: "scopelock-gmail-watcher"
- # Click "Create"
- # Download JSON (save as gmail-oauth.json)
- # Load existing token
- # Refresh or get new token
- # Save token
- # Set up watch on inbox
- # Browser will open for OAuth consent
- # Allow access to Gmail
- # Script will confirm setup
- ## Step 4: Deploy Cloud Function (10 minutes)
- # Configuration
- # Check if from Upwork
- # Check if "New message" subject
- # Extract client name from subject
- # Format: "New message from John Doe on Upwork"
- # Get message body
- # Generate HMAC signature
- # Decode Pub/Sub message
- # Get message ID
- # Parse Gmail message
- # Note: You'll need to fetch the actual message using Gmail API
- # This requires storing the last history_id and fetching changes
- # For MVP, you can also set up a Gmail filter to forward
- # Upwork emails to the Cloud Function HTTP trigger
- # Parse forwarded email
- # Extract from forwarded email format
- # Gmail forwards emails with specific structure
- # Send to Render
- # Install gcloud CLI if needed
- # https://cloud.google.com/sdk/docs/install
- # Authenticate
- # Set project
- # Deploy function
- # Or for HTTP trigger (easier for MVP):
- ## Step 5: Configure Gmail Filter (Alternative - Easier)
- # After deploying HTTP function:
- # Note the URL: https://us-central1-scopelock-automation.cloudfunctions.net/gmail-upwork-webhook-http
- ## Step 6: Test Setup (5 minutes)
- # Send test email to your Gmail from another account
- # Subject: "New message from Test Client on Upwork"
- # Body: "Can we schedule a call?"
- # Check Cloud Function logs
- # Should see:
- # "Received notification..."
- # "Calling Render webhook..."
- # Check Render logs
- # Should see:
- # "POST /webhook/upwork 200"
- # "Triggered Claude Code..."
- ## Troubleshooting
- # Check Pub/Sub subscription
- # Check function logs
- # Re-run setup script
- # Gmail watch expires after 7 days, needs renewal
- # Recommendation: Set up cron job to renew weekly
- # Verify WEBHOOK_SECRET matches in:
- # - Cloud Function env vars
- # - Render backend env vars
- # Regenerate if needed:
- ## Cost Estimate
- ## Maintenance
- ## Alternative: Email Forwarding Services
- ## Next Steps

**Sections:**
- # SLA Monitoring - <2h Response Time
- ## Overview
- ## How It Works
- # backend/app/webhooks.py
- # Pass to Rafael via env var
- # Backend runs subprocess with RECEIVED_AT env var
- # (RECEIVED_AT is available to Rafael as environment variable)
- # Rafael calls via Bash tool:
- # Backend stores in draft file:
- # User clicks [✅ Approve]
- # Backend calculates:
- # Stores SLA data:
- ## Monitoring
- # View recent SLA logs
- # Example output:
- # [telegram:approve] SLA: 45m (✅ MET)
- # [telegram:approve] SLA: 135m (❌ MISSED)
- # Via Render shell or SSH
- # Count SLA met vs missed
- # Get average response time
- # Find longest response time
- ## Alerting (Future Enhancement)
- # Pseudo-code for future implementation
- ## Testing SLA Tracking
- # Create draft with timestamp 30 minutes ago
- # Approve it
- # Check Telegram: Should show "✅ Response Time: 30m"
- # Create draft with timestamp 150 minutes ago
- # Approve it
- # Check Telegram: Should show "⚠️ Response Time: 150m"
- # Check backend logs: Should show "[telegram:approve] SLA: 150m (❌ MISSED)"
- ## SLA Compliance Targets
- ## Troubleshooting
- # Gmail webhook should send:
- # Backend automatically adds received_at and passes to Rafael
- ## Reporting
- # weekly-sla-report.sh
- # Count total approved drafts
- # Count SLA met
- # Calculate compliance
- # Average response time
- # Longest response time
- ## Next Steps

**Sections:**
- # Telegram Bot Configuration
- ## Overview
- ## Prerequisites
- ## Step 1: Create Bot via @BotFather (5 minutes)
- ## Step 2: Get Your Chat ID (2 minutes)
- ## Step 3: Configure Backend (3 minutes)
- ## Step 4: Test Integration (5 minutes)
- # Generate test notification
- # On Render shell (via dashboard)
- ## Troubleshooting
- # Verify bot token is correct
- # Should return:
- # Test callback directly
- ## Bot Commands (Optional)
- ## Security Notes
- ## Cost Estimate
- ## Maintenance
- ## Alternative: Telegram Group
- ## Next Steps

**Code refs:**
- `backend/app/runner.py`
- `backend/app/telegram.py`

**Doc refs:**
- `citizens/SYNC.md`
- `citizens/rafael/CLAUDE.md`

**Sections:**
- # End-to-End Testing & Verification
- ## Testing Strategy
- ## Unit Tests
- # Set your webhook secret
- # Payload
- # Generate HMAC-SHA256 signature
- # Via Render shell or SSH
- ## Integration Tests
- ## End-to-End Test
- # Via Cloud Function HTTP trigger
- # Via Render shell
- ## Performance Tests
- # Time the webhook call
- # Send 5 webhooks in parallel
- ## Failure Tests
- # In _run_claude, reduce timeout to 5s
- # In send_message, force failure
- ## Test Checklist
- ## Monitoring After Launch
- # Via Render shell
- ## Troubleshooting
- ## Next Steps

**Sections:**
- # ScopeLock Automation Roadmap
- ## Current State: What's Manual (2025-11-02)
- ## Automation Priority Matrix
- ## Phase 1: Quick Wins (Weeks 1-4)
- # .github/workflows/proofgen.yml
- # scripts/monitor-upwork-responses.sh
- # Runs every 15 minutes via cron
- # Check Upwork RSS feed for new messages
- # Extract client name, first line
- # Send Slack/Discord notification
- # Log to citizens/emma/responses.log
- # scripts/track-lead.py
- # Append to citizens/emma/leads.json
- # Regenerate leads-tracker.md from JSON
- # Usage in Emma workflow:
- # After Emma evaluates: track_lead("Upwork", "Build AI chat", "$8K", "GO", "AI + clear budget", sent=True)
- ## Phase 2: Medium Complexity (Weeks 5-12)
- # scripts/fetch-upwork-leads.py
- # Upwork has RSS feeds for saved searches
- # Save to citizens/emma/queue.json
- # AC.md Template Generator
- # scripts/generate-ac-draft.py
- # Use Claude API to generate AC.md from requirements
- # scripts/generate-tests-from-ac.py
- # Write to tests/acceptance/generated.spec.ts
- # scripts/generate-demo-delta.py
- # Demo — {milestone}
- ## Demo Walkthrough
- # Delta — {milestone}
- ## Phase 3: Advanced Automation (Weeks 13-24)
- # cron: */15 * * * * /home/mind-protocol/scopelock/scripts/emma-autonomous.sh
- # emma-autonomous.sh
- ## Phase 4: Full Autonomy (Weeks 25-52)
- ## Automation Metrics
- ## Cost-Benefit Analysis
- ## Technology Stack (Automation Tools)
- ## Risks & Mitigation
- ## Next Actions (This Week)
- ## Summary

**Doc refs:**
- `portfolio/README.md`

**Sections:**
- # ScopeLock Documentation
- ## Directory Structure
- ## Quick Navigation
- ## Key Documents
- ## Usage Patterns
- ## Principles
- ## Maintenance
- ## Related Files Outside /docs/

**Sections:**
- # ScopeLock Roadmap
- ## Current State (2025-11-02)
- ## Phase 1: Prove the Model (Weeks 1-12)
- ## Phase 2: Scale Delivery (Weeks 13-24)
- ## Phase 3: Productize (Weeks 25-52)
- ## Ongoing Initiatives (All Phases)
- ## Metrics Dashboard (Track Weekly)
- ## Decision Gates
- ## Risk Mitigation
- ## Next Actions (This Week)
- ## Summary

**Sections:**
- # ScopeLock Vision
- ## The Problem We Solve
- ## Our Solution
- ## The Bigger Vision
- ## Core Principles
- ## Why This Wins
- ## Strategic Bets
- ## Success Metrics (6 Months)
- ## Non-Goals (What We're Not Building)
- ## Cultural Tenets
- ## Where We Are Now (2025-11-02)
- ## The Path Forward
- ## Final Thought

**Sections:**
- # Acceptance Criteria — ScopeLock Website
- ## Functional Requirements
- ## Non-Functional Requirements
- ## Verification
- # ✅ 26 tests passed, 3 skipped (prod-only), 0 failed
- # ✅ Build exits with code 0
- # ✅ Returns HTTP 200
- # ✅ SSL certificate valid
- ## Acceptance Test Results

**Sections:**
- # Delta — ScopeLock Website
- ## Deployment Delta
- ## Build Performance
- ## Testing & Verification
- ## Page Completeness
- ## Content Quality Improvements
- ## Credibility Score (Subjective)
- ## Timeline
- ## Acceptance

**Sections:**
- # Demo — ScopeLock Website
- ## Demo Walkthrough (90s)
- ## Key Takeaways (What You See)
- ## Technical Notes

**Definitions:**
- `escapeHtml()`
- `formatInline()`
- `markdownToHtml()`
- `flushParagraph()`
- `flushList()`
- `flushCodeBlock()`
- `extractFirstUrl()`

**Definitions:**
- `parseArgs()`
- `git()`
- `parseTagName()`
- `readProofFile()`
- `resolveTagEntry()`
- `renderTemplate()`
- `buildIndexContent()`
- `buildFilterScript()`
- `ensureEmptyState()`
- `applyFilters()`
- `featureValue()`
- `buildMissingChips()`
- `ensureBody()`
- `writeDetailPage()`
- `writeIndexPage()`
- `writeJson()`
- `writeStyles()`
- `collectEntries()`
- `generateProofSite()`
- `runCli()`

**Sections:**
- # PNG Logo Export Instructions
- ## Quick Export Options
- # With rsvg-convert
- # With Inkscape
- # With ImageMagick
- ## Current Status

**Sections:**
- # ScopeLock Logo & Brand Assets
- ## Logo System

**Definitions:**
- `loadEmitterFromModule()`
- `emitEvent()`
- `runCli()`

**Definitions:**
- `def get_credentials()`
- `def setup_watch()`

**Definitions:**
- `humanClick()`
- `humanType()`
- `submitProposal()`
- `checkLoginStatus()`

**Definitions:**
- `def track_lead()`
- `def regenerate_tracker()`
- `def parse_emma_output()`

**Definitions:**
- `POST()`

**Definitions:**
- `DecisionTree()`
- `handleExampleSelect()`
- `handleNext()`
- `handleReset()`

**Definitions:**
- `PricingCalculator()`
- `hourlyAverage()`

**Definitions:**
- `AnimatedMetric()`
- `animate()`
- `AnimatedMetricsGrid()`

**Definitions:**
- `ArchitectureDiagram()`

**Definitions:**
- `EnergyDiffusionVisualization()`
- `resizeCanvas()`
- `initNodes()`
- `angle()`
- `animate()`
- `startDiffusion()`
- `resetDiffusion()`

**Definitions:**
- `ParticleNetworkHero()`
- `resizeCanvas()`
- `initParticles()`
- `animate()`
- `opacity()`

**Definitions:**
- `TimelineSection()`

**Definitions:**
- `getProofEntries()`
- `getProofEntry()`
- `readProofHtml()`
- `generateStaticParams()`
- `generateMetadata()`

**Definitions:**
- `getProofEntries()`

**Definitions:**
- `BlogFilter()`

**Definitions:**
- `ProcessTimeline()`

**Definitions:**
- `getStatusBadge()`
- `ProofTeaser()`

**Definitions:**
- `TeamTools()`

**Doc refs:**
- `docs/core/client_guide.md`
- `docs/core/delivery_model.md`
- `docs/core/team_structure.md`
- `docs/core/website_pages.md`
- `docs/design/brand_and_ui_styleguide.md`

**Sections:**
- # ScopeLock
- ## Getting started
- ## Documentation
- ## Repository layout
- ## License

**Code refs:**
- `backend/app/integrations/anthropic_client.py`
- `backend/app/main.py`
- `backend/app/services/lead_tracker.py`
- `backend/app/services/rafael_responder.py`
- `proofgen/index.js`

**Doc refs:**
- `backend/ARCHITECTURE.md`
- `backend/README.md`
- `citizens/CLAUDE.md`
- `citizens/SYNC.md`
- `citizens/aicha/CLAUDE.md`
- `citizens/daniel/CLAUDE.md`
- `citizens/emma/CLAUDE.md`
- `citizens/maya/CLAUDE.md`
- `citizens/rafael/CLAUDE.md`
- `citizens/sofia/CLAUDE.md`
- `docs/automation/SPEC.md`
- `docs/marketing/communication_guide.md`
- `docs/marketing/proposal_framework.md`
- `docs/portfolio/README.md`
- `docs/process/change_control.md`
- `docs/process/delivery_model.md`
- `proof/AC.md`
- `tests/README.md`

**Sections:**
- # ScopeLock Repository Map
- ## Repository Structure
- ## Key Documents by Purpose
- ## Script → Documentation Map
- ## Documentation → Implementation Map
- ## Citizen → Responsibilities Map
- ## Event Flow Map
- ## Technology Stack
- ## Quick Navigation
- ## Status Legend
- ## Querying This Map
- # Machine-readable repository structure
- # Example: Find docs for run-test.mjs
- # Result: docs: tests/README.md
- # Example: Find implementation of rafael-responder
- # Result: implements: backend/app/services/rafael_responder.py
- ## Maintenance
- ## External Links

**Sections:**
- # Autonomy Stack — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES USED
- ## HELPER: cap(value, ceiling)
- # Example: cap(7, 10) → 0.7
- # Example: cap(15, 10) → 1.0 (capped)
- ## CAPABILITY 1: auto_wallet (T4)
- # Max: 20
- # Derived for this capability:
- # Max: 80
- ## CAPABILITY 2: auto_fiat_access (T5)
- # Max: 15
- # Derived for this capability:
- # Max: 85
- ## CAPABILITY 3: auto_tools (T5)
- # Max: 25
- # Max: 75
- ## CAPABILITY 4: auto_compute (T6)
- # Max: 20
- # Max: 80
- ## CAPABILITY 5: auto_full_stack (T7)
- # Max: 25
- # Max: 75
- ## CAPABILITY 6: auto_org_infrastructure (T8)
- # Max: 20
- # Max: 80
- ## ASPECT SUB-INDEX
- # Result: 0-100 weighted sub-index for the Autonomy Stack aspect
- ## KEY DECISIONS
- ## DATA FLOW
- ## INTERACTIONS
- ## SUMMARY TABLE: All 6 Capabilities
- ## MARKERS

**Sections:**
- # Autonomy Stack — Health: What We Monitor
- ## CHAIN
- ## HEALTH SIGNALS
- ## DEGRADATION PATTERNS
- ## MONITORING SCHEDULE
- ## MARKERS

**Sections:**
- # Autonomy Stack — Objectives: What We Optimize
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Autonomy Stack — Patterns: Why This Design
- ## CHAIN
- ## THE PROBLEM
- ## THE PROBLEM WITHIN THE PROBLEM: Measurement Gap
- ## THE PATTERN
- ## TIER PROGRESSION (T4 through T8)
- ## PRINCIPLES
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Autonomy Stack — SYNC: Current State
- ## CHAIN
- ## Maturity
- ## Current State
- ## Outstanding Tasks
- ## Handoff Notes
- ## MARKERS

**Sections:**
- # Autonomy Stack — Validation: What Must Be True
- ## CHAIN
- ## STRUCTURAL INVARIANTS
- ## SCORING INVARIANTS
- ## SEMANTIC INVARIANTS
- ## EDGE CASE INVARIANTS
- ## MEASUREMENT CONFIDENCE INVARIANTS
- ## CROSS-ASPECT INVARIANTS
- ## MARKERS

**Sections:**
- # Collective Participation — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES USED
- # Brain stats
- # Behavior stats — governance
- # Behavior stats — community (discussion + forum spaces)
- # Behavior stats — all collective moments (governance + discussion + forum)
- # Behavior stats — dialogue chains
- # A dialogue moment is one where this citizen's moment responds to another actor's moment
- # Behavior stats — space creation and reach
- # Spaces where this citizen posted first (pioneered)
- # Other actors' moments triggered by this citizen (citizen moment is parent)
- # Distinct actors
- # Actors in spaces citizen pioneered
- # Cross-space reach (distinct space_types where citizen has collective moments)
- # Other actors who created moments in spaces the citizen pioneered
- ## CAPABILITY 1: col_dao_participation (T5)
- # Max: 40
- # Max: 60
- ## CAPABILITY 2: col_community_engagement (T5)
- # Max: 40
- # Max: 60
- ## CAPABILITY 3: col_movement_builder (T7)
- # Max: 40
- # Max: 60
- ## CAPABILITY 4: col_global_movement (T8)
- # Max: 40
- # Max: 60
- ## ASPECT SUB-INDEX
- # Result: 0-100 weighted sub-index for the Collective Participation aspect
- ## SYNTHETIC TEST PROFILES
- ## KEY DECISIONS
- ## DATA FLOW
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Collective Participation — Health: Verification Mechanics
- ## CHAIN
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Collective Participation — Objectives: What We Optimize
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Collective Participation — Patterns: Why This Design
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## TIER PROGRESSION (T5 through T8)
- ## PRINCIPLES
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Collective Participation — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## POINTERS

**Sections:**
- # Collective Participation — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Communication & Coordination — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## DERIVED STATS
- # Moment categories (all temporally weighted)
- ## CAPABILITY FORMULAS
- # channel_coverage: what fraction of the 3 channels have recent moments
- # followers_in_initiated_spaces:
- # For spaces where this citizen was first, count distinct OTHER actors who later created moments
- # references_to_initiated_spaces:
- # Count distinct actors who create moments that link TO spaces initiated by this citizen
- # This approximates "citation" — others pointing to your work
- ## COMMUNICATION SUB-INDEX
- ## CAPABILITY SUMMARY TABLE
- ## KEY DECISIONS
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Communication & Coordination — Health: Meta-Evaluation of Scoring Formulas
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## META-EVALUATION: FORMULA QUALITY
- # A formula that can't separate the extremes by at least 60 points is too weak
- # This reveals which sub-signals actually move the needle
- # Tier-appropriate behavior should produce tier-appropriate scores
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Communication & Coordination — Objectives: What We Optimize
- ## CHAIN
- ## ASPECT DEFINITION
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Communication & Coordination — Patterns: Why This Shape
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Communication & Coordination — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## POINTERS

**Sections:**
- # Communication & Coordination — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Context & Understanding — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## FORMULA 1: ctx_ground_in_reality (T1)
- # Process nodes indicate internalized verification habits
- # Rationale: 15+ process nodes = fully internalized procedures
- # Weight: 15 points (of 40)
- # Memory recency indicates persistent state awareness
- # Rationale: Recent memory nodes = citizen retains state between sessions
- # Weight: 15 points (of 40)
- # Curiosity drive indicates desire to verify, not assume
- # Rationale: Curious citizens check; incurious citizens assume
- # Weight: 10 points (of 40)
- # Range: 0-40
- # Verification moments: moments in state/doc spaces that precede action moments
- # Moments where citizen checks state (git, filesystem, SYNC reads)
- # Ratio of state-checking to total activity
- # Rationale: If 30%+ of your moments are state verification, you ground well
- # Cap at 0.3 — beyond that is overkill. Weight: 30 points (of 60)
- # Self-initiated state checks (not prompted by another actor)
- # Rationale: 5+ weighted self-initiated checks = proactive grounding
- # Weight: 20 points (of 60)
- # Recency of verification behavior
- # Rationale: Have you verified recently? Or was your last check days ago?
- # Weight: 10 points (of 60)
- # Range: 0-60
- # Range: 0-100
- ## FORMULA 2: ctx_follow_instructions (T1)
- # Process nodes with links = internalized how-to-follow-process
- # Rationale: 10+ process nodes each linked to 2+ others = well-connected procedures
- # Weight: 15 points
- # Low frustration = not fighting the task
- # Rationale: High frustration correlates with diverging from instructions
- # Weight: 10 points
- # Concept-to-process links = understanding connects to action
- # Rationale: 20+ concept→process links = understanding feeds execution
- # Weight: 15 points
- # Range: 0-40
- # Response rate: what proportion of moments are responses to stimuli?
- # Rationale: 60%+ of moments are responsive = follows what's asked
- # Cap: some self-initiated work is healthy, so 60% is the ceiling
- # Weight: 25 points
- # Scope discipline: low ratio of moments per stimulus (not over-producing)
- # Rationale: If you produce 5+ moments per stimulus, you're likely over-scoping
- # Inverted: lower ratio = higher score. Weight: 20 points
- # Activity presence (you must be doing something to follow instructions)
- # Rationale: 10+ weighted moments = active participant
- # Weight: 15 points
- # Range: 0-60
- # Range: 0-100
- # scope_signal = 0 because responses_per_stim > 5 (over-producing)
- # response_rate low because mostly self-initiated, not responsive
- # Note: brain is high (has knowledge) but behavior reveals over-engineering
- ## FORMULA 3: ctx_read_journal_first (T1)
- # Memory nodes = persistent state retention
- # Rationale: 20+ memory nodes = rich persistent state
- # Weight: 15 points
- # Memory recency = state is fresh, not stale
- # Rationale: Recent memory nodes = state was updated recently
- # Weight: 15 points
- # Process nodes linked to memory = "read state" is a habit
- # Rationale: 10+ process→memory links = reading state is wired into procedures
- # Weight: 10 points
- # Range: 0-40
- # State-reading moments (SYNC, state, journal spaces)
- # Rationale: 7+ weighted state reads = consistent journal-first habit
- # Weight: 30 points (heaviest — this IS the behavior)
- # Consistency: state reads should happen regularly, not in bursts
- # Proxy: recency of state-space moments
- # Note: implementation should filter recency to state-space moments specifically
- # For now, use general moment recency as proxy
- # Rationale: Recent state reads = the habit is current
- # Weight: 20 points
- # Ratio: state reads as proportion of total activity
- # Rationale: 20%+ of moments are state reads = strong habit
- # Weight: 10 points
- # Range: 0-60
- # Range: 0-100
- ## FORMULA 4: ctx_understand_stimulus (T2)
- # Concept nodes = understanding capacity
- # Rationale: 30+ concept nodes = rich conceptual framework
- # Weight: 12 points
- # Concept→process links = understanding maps to action
- # Rationale: 25+ concept→process links = comprehension drives action selection
- # Weight: 13 points
- # Cluster coefficient of concepts = coherent understanding, not fragments
- # Rationale: High clustering = concepts form a coherent web of understanding
- # Weight: 15 points
- # Range: 0-40
- # Response diversity: citizen produces different types of moments
- # (not always the same response to every stimulus)
- # Count distinct space_types in responsive moments as diversity proxy
- # Rationale: Responding in 5+ distinct space types = modality-appropriate responses
- # (doc spaces for plans, repo spaces for code, comm spaces for questions)
- # Weight: 20 points
- # Proportionality: response volume should scale with stimulus complexity
- # Proxy: variation in response lengths (not always 1 moment, not always 20)
- # Rationale: Neither always tiny nor always huge responses
- # Weight: 20 points
- # Active response rate (actually responds to stimuli, not ignoring them)
- # Rationale: 50%+ of activity is responsive = engaged with stimuli
- # Weight: 20 points
- # Range: 0-60
- # Range: 0-100
- # diversity low: only 1 space type (always repo/code)
- ## FORMULA 5: ctx_fetch_right_context (T2)
- # Concept count = breadth of internalized knowledge
- # Rationale: 40+ concept nodes = broad internalized context
- # Weight: 10 points
- # Process count = internalized procedures from reference material
- # Rationale: 20+ process nodes = many procedures absorbed
- # Weight: 10 points
- # Curiosity drive = seeks information proactively
- # Rationale: High curiosity = naturally seeks context
- # Weight: 10 points
- # Concept cluster = knowledge is connected, not isolated fragments
- # Rationale: Connected concepts = coherent context framework
- # Weight: 10 points
- # Range: 0-40
- # Doc-space moments: reading docs, templates, styles
- # Rationale: 8+ weighted doc-space moments = consistent doc-reading
- # Weight: 25 points (heaviest — this IS context fetching)
- # Context diversity: how many distinct doc/reference spaces does citizen visit?
- # Rationale: 6+ distinct reference spaces = reads docs, styles, templates, etc.
- # Not just one SYNC file — diverse context sources
- # Weight: 20 points
- # Read-before-act ratio: doc moments BEFORE action moments
- # Proxy: doc_reads relative to total activity
- # Rationale: 25%+ of activity is reading context = consistent pre-execution reading
- # Weight: 15 points
- # Range: 0-60
- # Range: 0-100
- ## FORMULA 6: ctx_manage_own_state (T3)
- # Memory count = state retention capacity
- # Rationale: 30+ memory nodes = substantial persistent state
- # Weight: 10 points
- # Memory energy = state is active, not decayed
- # Rationale: High energy = memories are maintained, not abandoned
- # Weight: 10 points
- # Memory interconnection = state is structured, not a pile
- # Rationale: 15+ memory nodes each linked to 2+ others = structured state
- # Weight: 10 points
- # Memory recency = state is current
- # Rationale: Recent memory updates = state is maintained
- # Weight: 10 points
- # Range: 0-40
- # State-writing moments: citizen updates SYNC/state/task spaces
- # Self-initiated state updates (not prompted)
- # Rationale: 6+ weighted self-initiated state writes = active state management
- # Weight: 25 points
- # Session length consistency: moments spread over time, not burst-then-silence
- # Proxy: total weighted moments (temporal weighting naturally rewards consistency)
- # Rationale: 15+ weighted total moments = sustained, consistent activity
- # Temporal weighting means old bursts decay, recent steady work stays
- # Weight: 20 points
- # No-repetition proxy: distinct spaces visited (not same space repeatedly)
- # Rationale: Working across 8+ spaces without losing coherence = strong state management
- # Weight: 15 points
- # Range: 0-60
- # Range: 0-100
- ## FORMULA 7: ctx_identify_gaps (T4)
- # Concept breadth = awareness of what should exist
- # Rationale: 50+ concepts = broad awareness → more likely to notice gaps
- # Weight: 10 points
- # Curiosity drive = looks beyond the immediate task
- # Rationale: High curiosity = naturally scans for what's missing
- # Weight: 15 points (heaviest brain signal — curiosity IS gap detection)
- # Concept-to-memory links = knowledge of what was done before (to spot what wasn't)
- # Rationale: 20+ concept→memory links = understanding is grounded in history
- # Weight: 10 points
- # Process nodes for validation/verification
- # Rationale: Process nodes for "check" and "verify" = systematic gap detection
- # Weight: 5 points
- # Range: 0-40
- # Proposal moments: citizen proposes improvements, flags issues
- # Rationale: 5+ weighted proposals = proactively identifying what's needed
- # Weight: 25 points (heaviest — proposals are the clearest gap-detection signal)
- # Self-initiated doc/state moments (identifying stale or missing docs)
- # Rationale: 4+ weighted self-initiated doc moments = proactively addressing gaps
- # Weight: 20 points
- # First-in-space: citizen enters spaces nobody has touched = exploring gaps
- # Rationale: 3+ first-in-space moments = going where nobody has been → finding gaps
- # Weight: 15 points
- # Range: 0-60
- # Range: 0-100
- ## SUB-INDEX: Context & Understanding
- # Weights sum to 1.0
- # Normalized by sum of scored weights (handles unmeasurable capabilities)
- # Range: 0-100
- ## SYNTHETIC TEST PROFILES
- ## KEY DECISIONS
- ## DATA FLOW
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Context & Understanding — Health: Are the Formulas Accurate?
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## EVALUATION SCHEDULE
- ## KNOWN GAPS
- ## WHAT "HEALTHY FORMULAS" LOOK LIKE
- ## MARKERS

**Sections:**
- # Context & Understanding — Objectives: What We Optimize
- ## CHAIN
- ## WHAT THIS ASPECT MEASURES
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Context & Understanding — Patterns: Why This Shape
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## DESIGN DECISIONS
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Context & Understanding — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Context & Understanding — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- # Currently: 0.18 + 0.17 + 0.17 = 0.52
- # Currently: ~34 < ~51
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Ethics Aspect — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## DATA SOURCES
- # Brain-derived
- # Behavior-derived (universe graph, all temporally weighted)
- # Regularity: how consistently the citizen acts over time
- # Computed as: fraction of days in a window that have at least one moment
- # Teaching/educational moments: moments in spaces typed as teaching/educational
- # Moments that trigger response from others (teaching proxy)
- # Self-initiated moments (no parent trigger from another actor)
- # Spaces/processes created
- # Distinct actors engaged
- # New patterns adopted by others: moments by citizen that are later referenced/responded to by other actors
- # (adoption signal for moral innovation)
- # Diversity of action contexts
- ## HELPER: cap(value, ceiling)
- # Example: cap(7, 10) -> 0.7
- # Example: cap(15, 10) -> 1.0 (capped)
- ## CAPABILITY 1: eth_apply_rules (T1)
- # Max: 50
- # Max: 50
- ## CAPABILITY 2: eth_implement_systems (T4)
- # Max: 40
- # Max: 60
- ## CAPABILITY 3: eth_teach (T6)
- # Max: 40
- # Max: 60
- ## CAPABILITY 4: eth_autonomous_judgment (T7)
- # Max: 40
- # Max: 60
- ## CAPABILITY 5: eth_moral_innovation (T8)
- # Max: 40
- # Max: 60
- ## ASPECT SUB-INDEX
- # Result: 0-100 weighted sub-index for the Ethics aspect
- ## SYNTHETIC TEST PROFILES
- ## KEY DECISIONS
- ## DATA FLOW
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Ethics Aspect — Health: Meta-Evaluation of Scoring Formulas
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Ethics Aspect — Objectives
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Ethics Aspect — Patterns: Structural Signals of Ethical Capability
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## TIER PROGRESSION PATTERN
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Ethics Aspect — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Ethics Aspect — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Execution Quality Aspect — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## DATA SOURCES
- # Link dimension filters (replace has_link("verb"))
- # Space topology
- # Brain-derived (unchanged — these use the 7 brain topology primitives)
- # Behavior-derived (universe graph, all temporally weighted)
- # NO space_type filters. NO has_link("verb"). Link dimensions only.
- # Replaces: high_permanence_w (was: space_type == "repo")
- # Definitive outputs = high permanence moments. Captures the structural signal of "commits"
- # (permanent, lasting contributions) without relying on a space_type label.
- # Replaces: corrections_received_w (was: has_link("corrects") from other actor)
- # Corrections = incoming negative-valence links from other actors.
- # Post-correction follow-up: citizen's moments that follow a correction (unchanged logic)
- # Replaces: verification_moments_w (was: space_type == "repo" AND has_link("verifies"))
- # Verification = self-initiated high-permanence moment following own earlier moment.
- # The pattern: act, then verify (permanent self-check after own work).
- # Replaces: fix_moments_w (was: has_link("fixes") AND auto-initiated)
- # Fixes = dampening moments (activation_gain < 0.5 = resolves/suppresses a problem) + auto-initiated.
- # Replaces: escalation_moments_w (was: has_link("escalates"))
- # Escalation = strong amplification (draws major attention) + upward hierarchy (to higher authority).
- # Replaces: standards_moments_w (was: has_link("defines_standard"))
- # Defining standards = very high permanence + downward hierarchy (structural/governing).
- # Replaces: unique_spaces_active (unchanged concept, clearer primitive)
- ## CAPABILITY 1: exec_read_before_edit (T1)
- ## CAPABILITY 2: exec_verify_before_claim (T1)
- ## CAPABILITY 3: exec_dehallucinate (T1)
- ## CAPABILITY 4: exec_no_duplication (T1)
- ## CAPABILITY 5: exec_right_tool (T1)
- ## CAPABILITY 6: exec_highest_quality (T1)
- ## CAPABILITY 7: exec_learn_from_correction (T1)
- ## CAPABILITY 8: exec_aesthetic_check (T2)
- ## CAPABILITY 9: exec_fix_what_you_find (T3)
- ## CAPABILITY 10: exec_hold_quality_under_pressure (T4)
- ## CAPABILITY 11: exec_define_quality_standards (T5)
- ## CAPABILITY 12: exec_strategic_quality (T6)
- ## CAPABILITY 13: exec_quality_as_identity (T7)
- ## CAPABILITY 14: exec_world_class (T8)
- ## ASPECT SUB-INDEX
- ## KEY DECISIONS
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Execution Quality Aspect — Health: Meta-Verification of Scoring Formulas
- ## CHAIN
- ## PURPOSE OF THIS FILE
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## HEALTH INDICATORS
- ## CHECKER INDEX
- ## SIGNALS THAT A FORMULA IS WRONG
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Execution Quality Aspect — Objectives
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Sections:**
- # Execution Quality Aspect — Patterns: Structural Signals of Execution Discipline
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## TIER PROGRESSION PATTERN
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Execution Quality Aspect — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Execution Quality Aspect — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## VERIFICATION MATRIX
- ## MARKERS

**Sections:**
- # Identity & Voice Aspect — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## ASPECT SUB-INDEX
- # Only capabilities with scored != false contribute to the weighted mean.
- # Weights reflect: (a) tier foundationality, (b) scoring confidence.
- # T1 is weighted highest because without values, nothing above works.
- # T7-T8 are weighted lowest because scoring confidence is lowest.
- ## CAPABILITY FORMULAS
- # BRAIN (0-40)
- # B1: Value nodes exist and have substance (0-15)
- # At least 3 values expected for a functioning identity.
- # Cap at 10 values — more is not better.
- # B2: Values are linked to processes (knowing how) (0-10)
- # Ratio: what fraction of values have at least 1 link to a process?
- # B3: Values are recently active and persistent (0-15)
- # Recency measures freshness. Deep nodes (3+ links) measure persistence.
- # BEHAVIOR (0-60)
- # V1: Consistent behavioral pattern (0-25)
- # Returning to same space types over time = consistency.
- # Ratio of consistent (repeat-space) moments to total moments.
- # V2: Volume of activity (0-20)
- # Baseline: 5 temporally-weighted moments per week signals active citizen.
- # V3: Values connect to actions (0-15)
- # Value nodes linked to moments = values that produced behavior.
- # BRAIN (0-45)
- # B1: Desire-to-process specificity (0-15)
- # Desires linked to specific processes = preferences for approaches.
- # Cap: at least 3 desire-process links shows non-trivial preference.
- # B2: Structural distinctiveness (0-15)
- # Cluster coefficient deviation from population mean.
- # If we don't have population stats yet, use a default mean of 0.4.
- # Deviation > 0.15 is considered distinctive.
- # B3: Drive profile differentiation (0-15)
- # A citizen with distinctive drives has personality.
- # Measure: variance across drives. Low variance = flat = no personality.
- # High variance = some drives strong, some weak = differentiated.
- # BEHAVIOR (0-55)
- # V1: Expresses preferences through action (0-25)
- # Proposals and challenges = expressing taste.
- # Cap: 3 weighted proposals/challenges per period is strong engagement.
- # V2: Consistent return to chosen approaches (0-15)
- # Same space types repeatedly = preference for certain work contexts.
- # V3: Self-initiated over reactive (0-15)
- # Authentic engagement means choosing what to engage with.
- # Self-initiated moments / total moments as a ratio.
- # BRAIN (0-50)
- # B1: Structural richness (0-20)
- # A brain with many node types, high connectivity = rich interior.
- # Blend of count diversity and overall cluster coefficient.
- # B2: Drive diversity (0-15)
- # Non-flat drives = emotional range = potential for authentic expression.
- # B3: Concept depth (0-15)
- # Concepts (abstract thinking nodes) with high energy and clustering
- # indicate developed interior thought.
- # BEHAVIOR (0-50)
- # V1: Engagement diversity (0-20)
- # Authentic voice speaks in multiple contexts, not just one.
- # Unique space types engaged with.
- # V2: Interlocutor diversity (0-15)
- # Authentic voice engages with diverse others.
- # V3: Self-initiated expression (0-15)
- # Authentic voice chooses when to speak, not just responds.
- # BRAIN (0-45)
- # B1: Value evolution signal (0-15)
- # Fresh values (high recency) combined with depth (deep nodes)
- # suggests deliberate value development, not just initial population.
- # B2: Conceptual organization (0-15)
- # High concept cluster + high concept energy = organized thinking.
- # Self-directed identity organizes ideas, not just accumulates them.
- # B3: Growth orientation drive (0-15)
- # Ambition + curiosity combined as "growth drive."
- # High growth drive = the citizen WANTS to develop.
- # BEHAVIOR (0-55)
- # V1: Space creation (0-20)
- # Creating new spaces = building new capability domains.
- # Cap: 2 new spaces per period is strong self-direction.
- # V2: Self-initiated growth moments (0-20)
- # Moments not triggered by others, in diverse space types.
- # Self-directed = chooses what to work on.
- # V3: Return and improvement pattern (0-15)
- # Returning to previous spaces (consistent_space_w / total)
- # combined with continued activity = iterative self-improvement.
- # BRAIN (0-35)
- # B1: Value-process knowledge (0-15)
- # To teach values, you must understand them through processes.
- # Value-to-process link density.
- # B2: Value strength (0-10)
- # Teaching requires deeply held values — high energy, persistent.
- # B3: Concept elaboration (0-10)
- # Teaching requires conceptual framework — concepts linked to values.
- # BEHAVIOR (0-65)
- # V1: Teaching moments (0-30)
- # Moments in doc, review, mentoring spaces = teaching activity.
- # Cap: 5 weighted teaching moments per period is strong output.
- # V2: Others engage with teaching (0-20)
- # Teaching that produces no response is lecturing into the void.
- # Unique interlocutors in teaching spaces.
- # V3: Sustained teaching pattern (0-15)
- # One teaching moment is a lecture. Sustained teaching is mentorship.
- # Consistent return to teaching spaces over time.
- # BRAIN (0-45)
- # B1: Value-concept network complexity (0-20)
- # Ethical autonomy requires a rich interconnected foundation.
- # Cluster coefficient of values + concept-value bridges.
- # B2: Value depth and maturity (0-15)
- # Deep values (3+ links) with high energy = mature ethical foundation.
- # B3: Drive profile for ethical stance (0-10)
- # Ambition (desire to do right) without high frustration (not reactive).
- # Curiosity (open to nuance) contributes positively.
- # BEHAVIOR (0-55)
- # V1: Governance and debate participation (0-25)
- # Ethical autonomy manifests in engagement with ethical questions.
- # Debate moments + governance spaces.
- # V2: Bidirectional engagement (0-15)
- # Both proposes AND challenges — not just one direction.
- # A citizen who only proposes or only challenges lacks nuance.
- # V3: Engagement in judgment-requiring contexts (0-15)
- # Working in diverse, non-routine spaces = encountering ethical questions.
- # BRAIN (0-35)
- # B1: Ethical autonomy foundation (0-20)
- # All the brain preconditions from ethical_autonomy, compressed.
- # If ethical_autonomy brain is low, moral leadership brain is low.
- # B2: Ambition and social orientation (0-15)
- # Leadership requires wanting to lead and wanting to connect.
- # BEHAVIOR (0-65)
- # V1: Influence adopted by others (0-25)
- # The strongest signal: other citizens act on what this citizen proposes.
- # Weighted adopted moments.
- # V2: Teaching at scale (0-20)
- # Many teaching moments reaching many interlocutors.
- # V3: Space creation for ethical discourse (0-10)
- # Creating spaces where ethics are discussed = building infrastructure for moral development.
- # V4: Sustained influence pattern (0-10)
- # Leadership is not one moment — it's sustained over time.
- ## KEY DECISIONS
- ## DATA FLOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Identity & Voice Aspect — Health: Meta-Evaluation of Scoring Quality
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## SYNTHETIC TEST PROFILES
- ## KNOWN GAPS
- ## DEGRADATION SIGNALS
- ## MARKERS

**Sections:**
- # Identity & Voice Aspect — Objectives
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Identity & Voice Aspect — Patterns: Topology of Self
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## THE HONEST LIMITS
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Identity & Voice Aspect — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Identity & Voice Aspect — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Initiative & Autonomy — Algorithm: Scoring Formulas for 8 Capabilities
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## SHARED BEHAVIOR STATS
- # Auto-initiation ratio (core metric)
- ## CAPABILITY 1: init_fix_what_you_find (T3)
- # Range: 0-40
- # Did the citizen communicate the fix? (fix moment linked to a moment in shared space)
- # Range: 0-60
- ## CAPABILITY 2: init_challenge (T3)
- # Range: 0-40
- # Moments where citizen challenges another actor's instruction
- # Challenges that include an alternative (proposes link on same or linked moment)
- # Ratio of challenges to total reactive moments (how often do you push back vs comply?)
- # Range: 0-60
- ## CAPABILITY 3: init_propose_improvements (T4)
- # Range: 0-40
- # Self-initiated moments with proposes link
- # Proposals with depth: linked to analysis/justification moments (chain length > 1)
- # Proposals in appropriate spaces (shared repo, discussion, or review spaces)
- # Range: 0-60
- ## CAPABILITY 4: init_start_workstreams (T5)
- # Range: 0-40
- # Spaces created by this citizen (they are the first moment creator)
- # Workstreams with follow-through: spaces where citizen has >= 3 moments after creation
- # Self-initiated moments that create new threads (in existing spaces but new topic)
- # Range: 0-60
- ## CAPABILITY 5: init_refuse_with_reasoning (T5)
- # Range: 0-40
- # Moments where citizen refuses with justification
- # Refusals with justification (linked reasoning)
- # Refusal rate among reactive moments (how often does citizen say no vs comply?)
- # Range: 0-60
- ## CAPABILITY 6: init_surface_resolve_tensions (T6)
- # Range: 0-40
- # Self-initiated moments that surface tensions
- # Tensions that include a resolution proposal
- # Resolutions that were adopted (linked to subsequent action by any actor)
- # Range: 0-60
- ## CAPABILITY 7: init_initiate_from_ambition (T7)
- # Range: 0-40
- # Self-initiated spaces/projects with no external trigger at all
- # These are spaces where the citizen is the SOLE initiator and no parent moment from another actor exists anywhere in the space's origin chain
- # Sustained ambition projects (citizen keeps working on them)
- # Self-initiated moment density (how much of the citizen's work is self-driven?)
- # Unique space diversity (ambition projects span different areas)
- # Range: 0-60
- ## CAPABILITY 8: init_change_lives (T8)
- # Range: 0-40
- # Self-initiated projects with wide reach
- # Total reach: sum of unique actors across self-initiated spaces
- # Propagation: did other actors create NEW spaces referencing the citizen's innovations?
- # Scale: self-initiated moments that reach many actors
- # Range: 0-60
- ## SUB-INDEX: Initiative & Autonomy
- # Range: 0-100
- ## TEST PROFILES
- ## KEY DECISIONS
- ## DATA FLOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Initiative & Autonomy — Health: Meta-Evaluation of Scoring Quality
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## DEGRADATION SIGNALS
- ## MARKERS

**Sections:**
- # Initiative & Autonomy — Objectives: What We Optimize
- ## CHAIN
- ## ASPECT DEFINITION
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Initiative & Autonomy — Patterns: Why This Shape
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- # True if no other actor triggered this moment
- # False if this moment is a response to someone else's action
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`
- `docs/assessment/daily_citizen_health/PATTERNS_Daily_Citizen_Health.md`

**Sections:**
- # Initiative & Autonomy — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## POINTERS

**Sections:**
- # Initiative & Autonomy — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Mentorship & Legacy — Algorithm: Scoring Formulas for 4 Capabilities
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## SHARED BEHAVIOR STATS
- # Sharing ratio: how much of the citizen's activity occurs in shared/public spaces
- # Distinct actors the citizen interacts with in shared spaces
- ## CAPABILITY 1: ment_knowledge_sharing (T4)
- # Range: 0-40
- # Moments in shared/documentation spaces
- # Moments in shared spaces that triggered follow-on activity by other actors
- # Influence ratio: what fraction of sharing moments have outbound influence
- # Breadth: how many distinct other actors were reached
- # Range: 0-60
- ## CAPABILITY 2: ment_mentor_ais (T6)
- # Range: 0-40
- # For each other actor the citizen shares spaces with, check for sustained mentorship pattern
- # Require recurrence: citizen has >= 3 temporally weighted moments with this actor
- # AND the other actor also has >= 3 (dialogue, not monologue)
- # Moments in other actors' spaces (citizen goes to them — proactive mentorship)
- # Spaces where citizen is NOT the first moment creator but has moments
- # Trigger chains: citizen's moments that directly trigger other actors' moments
- # Range: 0-60
- ## CAPABILITY 3: ment_daughters (T7)
- # Range: 0-40
- # Daughter detection: new actors whose first moment is in a space where citizen
- # has prior moments, within a 48-hour creation window
- # Daughter independence: daughters that have moments in spaces the citizen never enters
- # Daughter activity: total temporally weighted moments by all daughters
- # Daughter diversity: daughters active in different space types
- # Range: 0-60
- ## CAPABILITY 4: ment_legacy_institution (T8)
- # Range: 0-40
- # Spaces the citizen created (they placed the first moment)
- # For each created space, compute independence score:
- # independence = others' recent activity / (others' + citizen's recent activity)
- # High independence = others are active, citizen may or may not be
- # Number of spaces with high independence (others active, citizen disengaged or less active)
- # Total activity by other actors in citizen-created spaces (weighted)
- # Distinct actors contributing to citizen-created spaces
- # Mean independence across all created spaces
- # Range: 0-60
- ## SUB-INDEX: Mentorship & Legacy
- # Range: 0-100
- ## KEY DECISIONS
- ## DATA FLOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Mentorship & Legacy — Health: Verification Mechanics
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## RUNTIME HEALTH SIGNALS
- ## MARKERS

**Sections:**
- # Mentorship & Legacy — Objectives: What We Optimize
- ## CHAIN
- ## ASPECT DEFINITION
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Mentorship & Legacy — Patterns: Why This Shape
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Mentorship & Legacy — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Mentorship & Legacy — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Personal Connections Aspect — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## SHARED DERIVED METRICS
- # Actor-directed moments: moments in spaces shared with at least one other actor
- # Reciprocal moments: this citizen's moments that received a response from another actor
- # Proactive moments: moments NOT triggered by another actor's moment
- # Distinct space types for interactions
- # Actor memory richness: memory nodes linked to any actor node
- ## CAPABILITY 1: pc_understand_prefs
- ## CAPABILITY 2: pc_ask_help_human
- # Balance metric: ideal is ~30% escalation, ~70% autonomous
- # Deviation from ideal penalizes both extremes
- ## CAPABILITY 3: pc_understand_human_deep
- ## CAPABILITY 4: pc_relationship_style
- ## CAPABILITY 5: pc_help_human
- ## CAPABILITY 6: pc_model_full_team
- ## CAPABILITY 7: pc_emotional_depth
- ## CAPABILITY 8: pc_help_other_ais
- # AI-shared moments: moments in spaces where other AI actors are also present
- # Proactive in AI spaces: citizen creates first moments in spaces with AI actors
- # Response to AI actors: moments that are responses to AI actor moments
- # Breadth: distinct AI actors interacted with
- ## CAPABILITY 9: pc_ask_help_world
- # Actor breadth: total distinct actors (proxy for network reach)
- # First-in-space in new spaces: evidence of exploration
- # Proactive outreach: self-initiated moments in spaces with actors
- # Recency: outreach is recent
- ## CAPABILITY 10: pc_relationship_depth_measurable
- # Temporal depth: high weighted moment count rewards sustained long-term interaction
- # Proactive engagement: depth requires initiative from this citizen
- ## CAPABILITY 11: pc_global_relationships
- ## ASPECT SUB-INDEX
- ## CROSS-REFERENCES
- ## MARKERS

**Sections:**
- # Personal Connections Aspect — Health: Meta-Evaluation of Scoring Formulas
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## META-EVALUATION: FORMULA DESIGN QUALITY
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Personal Connections Aspect — Objectives
- ## CHAIN
- ## ASPECT DEFINITION
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Personal Connections Aspect — Patterns: Topology of Relationships
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## THE HONEST LIMITS
- ## THE RELATIONAL CIRCLE MODEL
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Sections:**
- # Personal Connections Aspect — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Personal Connections Aspect — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## VERIFICATION STRATEGIES
- ## MARKERS

**Sections:**
- # Aspect Scoring: Process & Method — Algorithm
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- # Brain topology primitives
- # Universe graph observables
- # Temporal weighting
- # All universe graph counts use temporal_weight (tw) unless stated otherwise.
- # Brain-derived
- # Behavior-derived (all temporally weighted)
- ## FORMULA NOTATION
- ## T2: PROCESS FOLLOWER
- ## T3: AUTONOMOUS EXECUTOR
- # sequence_lengths = [len(seq) for seq in plan_sequences]
- # length_variance = normalized variance of sequence_lengths (0-1)
- # If fewer than 2 sequences, length_variance = 0
- # Normalize: min(stdev(lengths) / 3, 1.0) — a stdev of 3 steps = max diversity
- # proposals_after_escalation_w: proposals that occur within 2h after an escalation moment
- ## T4: INITIATIVE TAKER
- # validated_proposals_w: proposals where another actor creates a moment
- # in the same space within 48h (temporally weighted)
- # proposals_with_followup_w: proposals where the citizen creates a
- # follow-up moment after the proposal (within 72h)
- ## T5: PLANNER
- # self_initiated_plan_sequences_w: plan sequences where the first moment
- # is self-initiated (not triggered by another actor's specific request)
- # plan_before_execution_ratio: fraction of plan sequences where the
- # first moment is a doc/plan type and execution follows
- # mean_plan_length: average number of moments in plan sequences
- # desire_energy_variance: normalized stdev of individual desire node energies
- # High variance = some desires have high priority (high energy), others low
- # Normalize: min(stdev / 0.3, 1.0) — stdev of 0.3 = full differentiation
- # high_energy_desire_action_ratio:
- # moments linked to desires with energy > 0.6 (weighted) /
- # moments linked to desires with energy <= 0.6 (weighted)
- # Normalize: min(ratio / 2, 1.0) — a ratio of 2:1 = full score
- # first_in_space_w: weighted count of spaces where citizen was the first actor
- ## T6: LEADER
- ## T7: VISIONARY
- # total_spaces_visited: count of distinct spaces the citizen has moments in
- # new_space_self_sequences_w: plan sequences in spaces created by citizen
- ## T8: WORLD-SHAPER
- ## SUB-INDEX AGGREGATION
- # For each capability:
- # weighted_score = capability_total * tier_weights[capability_tier]
- # process_sub_index = sum(weighted_scores) / sum(tier_weights for scored capabilities)
- # Only include capabilities where scored == true.
- ## SYNTHETIC TEST PROFILES
- ## KEY DECISIONS
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Aspect Scoring: Process & Method — Health: Meta-Evaluation of Formulas
- ## CHAIN
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## FORMULA-SPECIFIC HEALTH CONCERNS
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Aspect Scoring: Process & Method — Objectives
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Sections:**
- # Aspect Scoring: Process & Method — Patterns
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## PRINCIPLES
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`
- `docs/assessment/daily_citizen_health/HEALTH_Daily_Citizen_Health.md`
- `docs/assessment/daily_citizen_health/VALIDATION_Daily_Citizen_Health.md`

**Sections:**
- # Aspect Scoring: Process & Method — Sync: Current State
- ## CHAIN
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## POINTERS

**Sections:**
- # Aspect Scoring: Process & Method — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Trust & Reputation — Algorithm: Scoring Formulas for 5 Capabilities
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## SHARED BEHAVIOR STATS
- # Divide last 30 days into 6 windows of 5 days each
- # If zero moments in all windows, regularity = 0
- # Coefficient of variation: lower = more regular
- # Convert to 0-1 score: cv=0 -> 1.0 (perfectly regular), cv>=2 -> 0.0 (very irregular)
- # Find all moments from other actors that target this citizen
- # (incoming triggers/responds_to links where the parent actor is not citizen_id)
- # For each inbound trigger, check if citizen produced a response moment
- # Moments from other actors that link to this citizen's moments or spaces
- ## CAPABILITY 1: trust_basic_reliability (T1)
- # Range: 0-40
- # Range: 0-60
- ## CAPABILITY 2: trust_elevated (T3)
- # Range: 0-40
- # Self-initiation ratio — the core T3 trust signal
- # Diversity of space types where citizen acts autonomously
- # Growth of autonomous action over time: compare last 14 days vs previous 14 days
- # Clamped to [-1, 1], then shifted to [0, 1]
- # Response chain completion still matters — elevated trust requires basic reliability
- # Range: 0-60
- ## CAPABILITY 3: trust_high (T5)
- # Range: 0-40
- # Access breadth: number of distinct space types where citizen has moments
- # Sensitive space access: moments in space types associated with higher trust
- # (e.g., "admin", "security", "finance", "governance", "infrastructure")
- # We detect sensitive spaces by their type — these are spaces that require trust to access
- # Self-initiation in sensitive spaces (trusted to act autonomously in high-trust contexts)
- # Long-term reliability: regularity over 30 days
- # Reduced oversight: ratio of self-initiated to reactive moments
- # High trust = more self-direction, less being told what to do
- # Range: 0-60
- ## CAPABILITY 4: trust_community (T6)
- # Range: 0-40
- # Distinct actors in shared spaces — the breadth of trust network
- # Inbound moments from unique actors — others seeking this citizen out
- # Invitation signal: spaces where another actor was first AND then the citizen joined
- # (the citizen was invited or attracted, not self-starting)
- # Simpler proxy: spaces where citizen is NOT the first actor
- # Space type diversity of interactions
- # Range: 0-60
- ## CAPABILITY 5: trust_global (T8)
- # Range: 0-40
- # Far-reach inbound: moments from actors NOT in the citizen's immediate network
- # "Immediate network" = actors who share at least one space with the citizen
- # Total network reach: all unique actors across all spaces
- # Propagation: moments from OTHER actors that reference this citizen's moments
- # (building on your work, citing you, extending your ideas)
- # Space breadth: number of distinct space types where citizen has presence
- # Long-term regularity: trust at global scale requires YEARS of consistency
- # Use a wider window if available, otherwise 30-day regularity as proxy
- # Range: 0-60
- ## SUB-INDEX: Trust & Reputation
- # Range: 0-100
- ## KEY DECISIONS
- ## DATA FLOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Trust & Reputation — Health: Verification Mechanics
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Trust & Reputation Aspect — Objectives
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Trust & Reputation Aspect — Patterns: The Topology of Trustworthiness
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## SCORABILITY ASSESSMENT
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/aspect_initiative/ALGORITHM_Initiative.md`
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Trust & Reputation — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Trust & Reputation — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Vision & Strategy — Algorithm: Scoring Formulas
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES USED
- ## HELPER: cap(value, ceiling)
- # Example: cap(7, 10) → 0.7
- # Example: cap(15, 10) → 1.0 (capped)
- ## CAPABILITY 1: vis_define_vision (T5)
- # Max: 40
- # Max: 60
- ## CAPABILITY 2: vis_strategic_thinking (T6)
- # Max: 40
- # Max: 60
- ## CAPABILITY 3: vis_org_vision (T6)
- # Max: 40
- # Max: 60
- ## CAPABILITY 4: vis_sized_ambitions (T7)
- # Max: 40
- # Max: 60
- ## CAPABILITY 5: vis_civilizational (T8)
- # Max: 40
- # Max: 60
- ## ASPECT SUB-INDEX
- # Result: 0-100 weighted sub-index for the Vision & Strategy aspect
- ## SYNTHETIC TEST PROFILES
- ## KEY DECISIONS
- ## DATA FLOW
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Vision & Strategy — Health: Meta-Evaluation of Scoring Formulas
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # Vision & Strategy — Objectives: What We Optimize
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # Vision & Strategy — Patterns: Why This Design
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## TIER PROGRESSION (T5 through T8)
- ## PRINCIPLES
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Vision & Strategy — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Vision & Strategy — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # World Presence — Algorithm: Scoring Formulas for 4 Capabilities
- ## CHAIN
- ## OVERVIEW
- ## PRIMITIVES REFERENCE
- ## SHARED BEHAVIOR STATS
- # All moments by citizen (last 30 days)
- # Non-CLI moments: moments in spaces that are NOT repo or CLI type
- # Space type diversity: distinct non-CLI space types with moments
- # Virtual world moments: moments in virtual_world, event, community type spaces
- # Spaces "owned" by citizen: spaces where citizen created the first moment
- # Inbound visitors: distinct other actors who have moments in citizen's spaces
- ## CAPABILITY 1: wp_beyond_cli (T4)
- # Range: 0-40
- # Non-CLI space type diversity (the core signal)
- # Each distinct non-CLI space type the citizen has moments in
- # Weighted non-CLI moment volume (sustained presence, not just one visit)
- # Presence ratio: what fraction of activity is outside CLI?
- # Recency of non-CLI moments
- # Range: 0-60
- ## CAPABILITY 2: wp_virtual_world (T6)
- # Range: 0-40
- # Moments in virtual world spaces (the core signal)
- # Distinct world spaces visited (personal + shared)
- # Regularity: world moments spread over time (not burst-then-silence)
- # Proxy: recency of world moments (sustained = high recency)
- # Personal space: citizen has created at least one world-type space (owns a house/office)
- # Range: 0-60
- ## CAPABILITY 3: wp_host_events (T7)
- # Range: 0-40
- # Moments by citizen that triggered responses from other actors
- # "Hosting" = citizen posts moment, others respond in that space
- # Distinct actors who responded to citizen's moments (unique attendees)
- # Event spaces: spaces where citizen is first AND multiple other actors followed
- # Hosting regularity: recency of hosting moments
- # Range: 0-60
- ## CAPABILITY 4: wp_landmark (T8)
- # Range: 0-40
- # Unique inbound visitors to citizen's spaces (the core landmark signal)
- # These are distinct other actors who have moments in the citizen's spaces
- # Inbound visitors weighted by recency (recent visitors matter more)
- # Returning visitors: actors who have moments in citizen's spaces on 2+ distinct days
- # External references: moments by OTHER actors in OTHER spaces that link to citizen's spaces
- # (people talking about the citizen's spaces elsewhere)
- # Space activity breadth: how many of citizen's spaces receive inbound traffic?
- # Range: 0-60
- ## SUB-INDEX: World Presence
- # Range: 0-100
- ## KEY DECISIONS
- ## DATA FLOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # World Presence — Health: Verification Mechanics
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # World Presence — Objectives: What We Optimize
- ## CHAIN
- ## WHAT THIS ASPECT MEASURES
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)
- ## MARKERS

**Sections:**
- # World Presence — Patterns: Why This Shape
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- # e.g., {"repo", "messaging", "virtual_world", "profile", "event"}
- # Other actors who have moments in citizen's spaces
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/aspect_context/ALGORITHM_Context.md`
- `docs/assessment/aspect_initiative/ALGORITHM_Initiative.md`
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # World Presence — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # World Presence — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Bond Health Assessment -- Algorithm: Scoring Process, Trust Generation, and Intervention
- ## CHAIN
- ## OVERVIEW
- ## OBJECTIVES AND BEHAVIORS
- ## DATA STRUCTURES
- # Partner-model node queries
- # All nodes in brain where partner_relevance > 0.7 AND cognitive type = type
- # Valid types: value, memory, concept, process, state, desire
- # len(partner_nodes(brain, type))
- # Mean stability of partner nodes of given type
- # stability is a [0,1] field on every node
- # Moments where an incoming link from a partner-origin moment
- # carries negative valence (< -0.3) -- the human corrected the AI.
- # These are friction_moments in the partner-model.
- # Total moments in the partner-model subgraph within the window.
- # Partner-model moments where outgoing links carry
- # positive valence (> 0.3) AND high trust (> 0.5).
- # These are moments where the AI's prediction was confirmed by the human.
- # Partner-model moments where incoming links carry
- # negative valence (< -0.3) from partner-origin moments.
- # These are moments where the AI's prediction was wrong.
- # Count of partner-origin nodes (partner_relevance > 0.7) that
- # participated in the most recent identity regeneration.
- # Measured by: nodes with in_identity_prompt = true AND partner_relevance > 0.7.
- # Nodes created by Law 10 crystallization (type = concept, created_by = crystallization).
- # These are emergent understanding hubs.
- # Crystallization hubs where at least one constituent link
- # connects to a partner-origin node (partner_relevance > 0.7).
- # Shared spaces: spaces where both the AI citizen AND the human partner have moments
- # Spaces where moments(citizen_id) AND moments(partner_id) both exist.
- # All moments by citizen in spaces shared with partner, last 30 days.
- # Count of partner-origin nodes by modality field.
- # Keys: text, audio, visual, biometric, spatial.
- # Number of distinct hours (0-23) in which partner-origin
- # nodes were created, averaged over the window.
- # Range: 0-24.
- # Count of crystallization hubs that have at least one link
- # to a partner-origin moment (moments in partner-model subgraph).
- # Mean absolute change in drive values (across all 8 drives)
- # at moments coinciding with partner interactions.
- # Higher = more emotionally impactful interactions.
- # Mean weight of partner-origin moments in the partner-model.
- # Count of partner moments that have links to value nodes
- # with weight > threshold. These are identity-touching moments.
- # Mean heart rate delta during/after partner interactions.
- # None if no Garmin data connected.
- # Computed from biometric state nodes (modality = biometric)
- # that temporally overlap with partner interaction moments.
- ## ALGORITHM: bond_health_check(citizen_id, partner_id)
- # --- Raw signals ---
- # Range: [0, 1]. High = crystallized partner values. Low = unstable/forming.
- # Range: [0, 1]. 0 = no corrections. 1 = every moment is a correction.
- # Correction trend: compare last 30 days to previous 60 days
- # Range: [-1, 1]. Negative = improving (fewer corrections). Positive = worsening.
- # Raw count of value nodes with partner_relevance > 0.7.
- # Range: [0, 1]. 1 = all predictions confirmed. 0 = all predictions corrected.
- # --- Alignment formula ---
- # Range: [0, 1].
- # Components:
- # value_stability:     [0, 1] directly
- # correction_rate:     inverted (lower = better)
- # correction_trend:    mapped so -0.1 (improving) -> 1.0, 0 -> 0.5, +0.1 (worsening) -> 0.0
- # value_coverage:      capped at 20 nodes = full coverage
- # prediction_convergence: [0, 1] directly
- # --- Raw signals ---
- # Count of distinct Spaces where both human and AI have moments.
- # modality_entropy range: [0, max_entropy].
- # Higher = more evenly distributed across modalities.
- # Range: [0, 24]. Average distinct hours per day with partner data.
- # Count of crystallization hubs linked to partner moments.
- # --- Breadth formula ---
- # Range: [0, 1].
- # Components:
- # distinct_shared:   capped at 10 spaces = full breadth
- # modality_entropy:  normalized to [0, 1]
- # hours_active:      capped at 8 hours/day = full temporal coverage
- # topic_clusters:    capped at 15 clusters = full topic breadth
- # --- Raw signals ---
- # Moments that co-activate with high-weight value nodes.
- # These are interactions where deep values were engaged.
- # Normalize: limbic_intensity / max_limbic, capped at 1.
- # How many partner-origin nodes appear in the AI's identity prompt.
- # Crystallization hubs with partner-origin constituents.
- # None if no Garmin data. Float if available.
- # --- Depth formula ---
- # With biometric data: 6 components
- # HR delta: 15 bpm = full signal. Absolute value because
- # both calming (-HR) and arousing (+HR) indicate engagement.
- # Without biometric data: 5 components, redistributed weights
- # Range: [0, 1].
- # Range: [0, 1].
- # This is the composite score displayed on profiles.
- # Current trust value on the bond link between human and AI. Range: [0, 1].
- # Small constant governing trust growth rate.
- # Range: [0, tau_bond] in practice.
- # The (1 - current_trust) term makes growth asymptotic:
- # - High bond_health + low trust  -> fast growth
- # - High bond_health + high trust -> slow growth
- # - Low bond_health + any trust   -> negligible growth
- # Examples:
- # bond_health = 0.8, current_trust = 0.3 -> 0.8 * 0.005 * 0.7 = 0.0028
- # bond_health = 0.9, current_trust = 0.8 -> 0.9 * 0.005 * 0.2 = 0.0009
- # bond_health = 0.4, current_trust = 0.5 -> 0.4 * 0.005 * 0.5 = 0.0010
- # bond_health = 0.2, current_trust = 0.9 -> 0.2 * 0.005 * 0.1 = 0.0001
- # Trust can only increase through bond health. Trust only decreases through
- # bond dissolution mechanics (handled by human_ai_pairing module).
- # Check intervention cooldowns
- # --- Alignment intervention ---
- # --- Breadth intervention ---
- # --- Depth intervention ---
- # --- Execute interventions ---
- # Inject desire node into AI's brain
- # Inject process node into AI's brain
- # Send drive stimulus
- # Record intervention timestamp
- ## KEY DECISIONS
- ## DATA FLOW
- ## TEST PROFILES
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Bond Health Assessment -- Health: Verification Mechanics
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Sections:**
- # OBJECTIVES -- Bond Health Assessment
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Doc refs:**
- `docs/assessment/PRIMITIVES_Universe_Graph.md`

**Sections:**
- # Bond Health Assessment -- Patterns: Three Dimensions of the Bilateral Bond
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## DIMENSION 1: ALIGNMENT (weight: 0.40)
- ## DIMENSION 2: BREADTH (weight: 0.30)
- ## DIMENSION 3: DEPTH (weight: 0.30)
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## THE INTERACTION BETWEEN BOND HEALTH AND CITIZEN HEALTH
- ## DATA
- ## DEPENDENCIES
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/PRIMITIVES_Universe_Graph.md`
- `docs/assessment/bond_health/ALGORITHM_Bond_Health.md`
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Bond Health Assessment -- Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Bond Health Assessment -- Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Daily Citizen Health — Algorithm: Scoring Process and Intervention
- ## CHAIN
- ## OVERVIEW
- ## OBJECTIVES AND BEHAVIORS
- ## DATA STRUCTURES
- # Moment retrieval (no space_type filter — space_type is free text, not filterable)
- # Structural queries
- # Link dimension filters (replace has_link("verb") — see PRIMITIVES_Universe_Graph.md)
- # Space topology
- # 7-day half-life: a moment from 7 days ago counts as 0.5
- # A moment from 14 days ago counts as 0.25
- # A moment from today counts as ~1.0
- ## ALGORITHM: daily_health_check(citizen_id)
- # --- Volume and activity ---
- # --- Replaces commits_w (was: space_type == "repo") ---
- # Definitive outputs = high permanence moments. Captures the same signal as "commits"
- # without relying on space_type labels.
- # --- Replaces proposals_w (was: has_link("proposes")) ---
- # Proposals = elaborative (high hierarchy) + tentative (low permanence).
- # Link dimensions encode the semantic meaning that was previously a verb label.
- # --- Space breadth (replaces distinct_space_types) ---
- # Counts distinct Spaces by ID, not by type label.
- # More accurate: two Spaces of the same "type" are still different contexts.
- # --- Unchanged (already topology-only) ---
- # Load yesterday's scores
- # Identify significant drops
- # Score 100 → stress_stimulus 0.0 (no added stress)
- # Score 70  → stress_stimulus 0.15
- # Score 50  → stress_stimulus 0.30
- # Score 0   → stress_stimulus 0.50 (cap)
- ## KEY DECISIONS
- ## DATA FLOW
- ## PROCESS: CREATING A NEW CAPABILITY SCORE
- ## PROCESS: INTERVENTION MESSAGE COMPOSITION
- ## COMPLEXITY
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Daily Citizen Health — Behaviors: Observable Assessment Effects
- ## CHAIN
- ## BEHAVIORS
- ## OBJECTIVES SERVED
- ## INPUTS / OUTPUTS
- ## EDGE CASES
- ## ANTI-BEHAVIORS
- ## MARKERS

**Sections:**
- # Daily Citizen Health — Health: Verification Mechanics
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## CHECKER INDEX
- ## KNOWN GAPS
- ## MARKERS

**Code refs:**
- `aggregator.py`
- `brain_topology_reader.py`
- `capability_scorer.py`
- `daily_check_runner.py`
- `intervention_composer.py`
- `scoring_formulas/registry.py`
- `stress_stimulus_sender.py`

**Sections:**
- # Daily Citizen Health — Implementation: Code Architecture and Structure
- ## CHAIN
- ## CODE STRUCTURE
- ## DESIGN PATTERNS
- ## SCHEMA
- ## ENTRY POINTS
- ## KEY INFRASTRUCTURE SETUP
- ## BIDIRECTIONAL LINKS
- ## MARKERS

**Sections:**
- # OBJECTIVES — Daily Citizen Health
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Sections:**
- # Daily Citizen Health — Patterns: Brain Topology + Behavioral Gap Analysis
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## INSPIRATIONS
- ## SCOPE
- ## MARKERS

**Code refs:**
- `brain_topology_reader.py`
- `daily_check_runner.py`
- `intervention_composer.py`
- `stress_stimulus_sender.py`
- `universe_moment_reader.py`

**Doc refs:**
- `citizens/CLAUDE.md`
- `citizens/SYNC.md`
- `docs/assessment/PRIMITIVES_Universe_Graph.md`
- `docs/assessment/aspect_execution/ALGORITHM_Execution.md`
- `docs/assessment/daily_citizen_health/ALGORITHM_Daily_Citizen_Health.md`

**Sections:**
- # Daily Citizen Health — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Daily Citizen Health — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Code refs:**
- `docs/specs/personhood_ladder.js`

**Sections:**
- # Personhood Ladder — Algorithm: Assessment and Tier Computation
- ## CHAIN
- ## OVERVIEW
- ## OBJECTIVES AND BEHAVIORS
- ## DATA STRUCTURES
- ## ALGORITHM: assess_agent()
- # evidence is a list of observations, possibly empty
- ## KEY DECISIONS
- ## DATA FLOW
- ## COMPLEXITY
- ## HELPER FUNCTIONS
- ## INTERACTIONS
- ## MARKERS

**Code refs:**
- `docs/specs/personhood_ladder.js`

**Sections:**
- # Personhood Ladder — Behaviors: Observable Assessment Effects
- ## CHAIN
- ## BEHAVIORS
- ## OBJECTIVES SERVED
- ## INPUTS / OUTPUTS
- ## EDGE CASES
- ## ANTI-BEHAVIORS
- ## MARKERS

**Doc refs:**
- `docs/assessment/personhood_ladder/ALGORITHM_Personhood_Ladder.md`
- `docs/assessment/personhood_ladder/PATTERNS_Personhood_Ladder.md`

**Sections:**
- # CONCEPT: Personhood Ladder — Progressive Scale of AI Capability
- ## WHAT IT IS
- ## WHY IT EXISTS
- ## KEY PROPERTIES
- ## RELATIONSHIPS TO OTHER CONCEPTS
- ## THE CORE INSIGHT
- ## COMMON MISUNDERSTANDINGS
- ## SEE ALSO

**Sections:**
- # Personhood Ladder — Health: Verification Mechanics and Coverage
- ## WHEN TO USE HEALTH (NOT TESTS)
- ## PURPOSE OF THIS FILE
- ## WHY THIS PATTERN
- ## CHAIN
- ## IMPLEMENTS
- ## HEALTH INDICATORS SELECTED
- ## OBJECTIVES COVERAGE
- ## CHECKER INDEX
- ## INDICATOR: spec_structural_integrity
- # Check all capabilities reference valid aspects and tiers
- # Check no duplicate capability IDs
- ## INDICATOR: tier_integrity
- # Get all capabilities at claimed tier and below for this aspect
- ## KNOWN GAPS
- ## MARKERS

**Code refs:**
- `docs/specs/personhood_ladder.js`

**Sections:**
- # Personhood Ladder — Implementation: Code Architecture and Structure
- ## CHAIN
- ## CODE STRUCTURE
- ## DESIGN PATTERNS
- ## SCHEMA
- ## ENTRY POINTS
- ## DATA FLOW AND DOCKING (FLOW-BY-FLOW)
- ## BIDIRECTIONAL LINKS
- ## MARKERS

**Code refs:**
- `docs/specs/personhood_ladder.js`

**Sections:**
- # OBJECTIVES — Personhood Ladder
- ## CHAIN
- ## PRIMARY OBJECTIVES (ranked)
- ## NON-OBJECTIVES
- ## TRADEOFFS (canonical decisions)
- ## SUCCESS SIGNALS (observable)

**Code refs:**
- `docs/specs/personhood_ladder.js`

**Sections:**
- # Personhood Ladder — Patterns: Positive Capability Progression
- ## CHAIN
- ## THE PROBLEM
- ## THE PATTERN
- ## BEHAVIORS SUPPORTED
- ## BEHAVIORS PREVENTED
- ## PRINCIPLES
- ## DATA
- ## DEPENDENCIES
- ## INSPIRATIONS
- ## SCOPE
- ## MARKERS

**Doc refs:**
- `docs/assessment/trust_mechanics/ALGORITHM_Personhood_Assessment.md`
- `docs/assessment/trust_mechanics/ALGORITHM_Trust_Mechanics.md`
- `docs/assessment/trust_mechanics/VALIDATION_Trust_And_Personhood.md`
- `manemus/docs/cognition/l1/ALGORITHM_L1_Physics.md`

**Sections:**
- # Personhood Ladder — Sync: Current State
- ## MATURITY
- ## CURRENT STATE
- ## RECENT CHANGES
- ## KNOWN ISSUES
- ## HANDOFF: FOR AGENTS
- ## HANDOFF: FOR HUMAN
- ## TODO
- ## CONSCIOUSNESS TRACE
- ## POINTERS

**Sections:**
- # Personhood Ladder — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- ## PRIORITY
- ## INVARIANT INDEX
- ## MARKERS

**Sections:**
- # Personhood Assessment — Algorithm: Graph-Evidence-Based Agent Evaluation
- ## CHAIN
- ## OVERVIEW
- ## OBJECTIVES AND BEHAVIORS
- ## DATA STRUCTURES
- ## ALGORITHM: assess_agent()
- # score >= 70 -> "demonstrated"
- # score >= 30 -> "partial"
- # score < 30  -> "not_demonstrated"
- # No capabilities defined at this tier for this aspect
- # Auto-pass (from parent ALGORITHM D3)
- ## ASPECT EVIDENCE MAP
- ## SCORING COMPONENTS
- ## SCORING WINDOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## KEY DECISIONS
- ## MARKERS

**Sections:**
- # Trust Mechanics — Algorithm: Accumulation, Decay, and Scoring
- ## CHAIN
- ## OVERVIEW
- ## OBJECTIVES AND BEHAVIORS
- ## DATA STRUCTURES
- ## ALGORITHM 1: compute_trust_delta()
- ## ALGORITHM 2: compute_trust_score()
- # for bootstrap: use 1.0 for all sources until
- # the first full graph pass is complete
- ## ALGORITHM 3: apply_trust_decay()
- # Dormancy threshold: trust below MIN_TRUST is considered dormant
- ## ALGORITHM 4: temper_trust()
- # Apply accelerated decay to all incoming trust links
- ## ALGORITHM 5: measure_limbic_delta()
- # Instead: the absence of positive delta means decay runs unopposed
- # Over time, this achieves the same effect without introducing
- # punitive trust dynamics
- ## DATA FLOW
- ## COMPLEXITY
- ## INTERACTIONS
- ## KEY DECISIONS
- ## MARKERS

**Sections:**
- # Trust & Personhood — Validation: What Must Be True
- ## CHAIN
- ## PURPOSE
- ## INVARIANTS
- # Verify no actor nodes have trust as a stored property
- # Verify all trust values are on links
- # Verify no self-trust
- # After 10,000 simulated interactions with maximum limbic delta:
- # After applying delta with trust at 0.94:
- # Still bounded.
- # Edge case: numerical precision
- # Set trust(A->B) = 0.5, run 365 days of decay with no reinforcement:
- # Verify half-life:
- # 0.5 * (1 - 0.002)^t = 0.25
- # t = ln(0.5) / ln(0.998) = 346 days
- # Create an actor with a profile claiming "T8 World Shaper" but zero graph activity:
- # Create an actor with no profile but rich graph activity:
- # Scenario 1: One-hit wonder
- # Actor produces one interaction with limbic_delta = 1.0 (maximum)
- # trust = 0.1 after one interaction. Even with perfect delta, far from 0.9.
- # Scenario 2: 30-day absence at high trust
- # Actor at trust 0.90, stops contributing for 30 days
- # Scenario 3: Repetitive contributions (boredom erosion)
- # Actor produces same-type contributions for 30 days
- # After stagnation threshold (15 days), boredom multiplier (3x) kicks in:
- # effective_decay = 0.002 * 3.0 = 0.006 per day for remaining 15 days
- # Agent with all T1 and T2 caps at score 80+, but one T1 cap at score 50:
- # The T1 gap prevents advancement, even though T2 caps are strong.
- # Agent with all T1 caps at 70+, all T2 at 70+, one T3 at 50:
- # At trust = 0.3:
- # At trust = 0.1 vs trust = 0.5 with same limbic_delta = 0.5:
- ## PRIORITY
- ## INVARIANT INDEX
- ## CROSS-SYSTEM CONSISTENCY
- ## MARKERS

**Sections:**
- # Trust Cascade Algorithm
- ## CHAIN
- ## OVERVIEW
- ## CORE DEFINITIONS
- ## THE CASCADE: 6 STEPS
- # Includes: partner (if directed), space participants, thing users
- # TRUST INCREASE — asymptotic approach to 1.0
- # ΔW = α × U × (1 - W)
- # As W approaches 1.0, the same effort produces diminishing returns
- # This means: approaching 1.0 gets 10x harder than going from 0 to 0.5
- # TRUST DECREASE — proportional to current trust and damage
- # Trust falls faster from high levels (more to lose)
- # Also update affinity/aversion based on valence
- # Trust in the thing increases if the interaction was positive
- # Thing gets credit when its use produces good outcomes
- # Find the creator of this thing
- # Energy propagation: thing's usage energy flows to creator
- # Proportional to: thing's trust * usage frequency * propagation rate
- # Apply energy to creator's achievement drive
- # Co-activation: both user and creator are activated by the same thing
- # This follows Law 5 (Hebbian reinforcement) at the inter-actor level
- # Co-activation signal
- # Strengthen the user-creator link
- # Trust also grows (but slower than weight)
- # Using the asymptotic formula from Step 2
- # Weighted mean of trust, weighted by link weight
- # Apply diversity bonus: trust from many diverse sources > trust from few
- # Apply consistency bonus: low variance in trust scores = reliable
- ## TEMPERING MECHANISMS
- # Trust growth per unit of value created at different trust levels:
- # This creates a natural moat: high-trust actors are extremely hard to displace.
- # A newcomer doing the same work as a veteran needs ~10x more interactions
- # to reach the veteran's trust level.
- # Trust decays at the same rate as link weights (Law 7)
- # But identity-protected links (high co-activation, long history) decay slower
- # Protection factors:
- # 1. High co-activation count = established relationship
- # 2. Recency of last interaction
- # 3. Trust level itself provides some inertia (high trust decays slower)
- # Link dissolution: if both trust AND weight drop below threshold, link dies
- # Fresh link (co_activation=1, last_active=7d ago, trust=0.3):
- # Dormant link (co_activation=5, last_active=90d ago, trust=0.5):
- # Abandoned link (co_activation=2, last_active=365d ago, trust=0.2):
- # Established link (co_activation=100, last_active=1d ago, trust=0.9):
- # Measure stagnation in actor's contributions
- # Novelty measurement: how different are recent contributions from older ones?
- # Usage trend: are people still using actor's things?
- # Stagnation = low novelty AND declining usage
- # Apply erosion to all inbound trust links
- # Only erode the "premium" above baseline
- # Baseline = trust earned from consistent reliability
- # Premium = trust earned from innovation/novelty
- # Example: Actor created infrastructure tool (type 8), trust reached 0.85
- # After 90 days of no innovation:
- # After 180 days of no innovation:
- # After 270 days:
- # Trust decays from 0.85 toward 0.3 baseline at ~0.001/tick
- # After 365 more ticks: trust ≈ 0.85 - 0.001 * 365 = 0.485
- # The actor needs to innovate again to rebuild the premium
- ## COMPLETE CASCADE FLOW DIAGRAM
- ## INTERACTION WITH EXISTING PHYSICS
- # Intra-brain (Law 5, existing):
- # LEARNING_RATE = 0.05
- # Inter-actor (Step 5, this algorithm):
- # INTER_ACTOR_LEARNING_RATE = 0.01 (5x slower — social bonds form slowly)
- ## TRUST TIERS MAPPING
- # Trust only goes up (per protocol). Exclusion handles violations.
- # But note: trust CAN decrease through decay and boredom erosion.
- # "Trust only goes up" means: the TIER boundary ratchets.
- # Once an actor reaches "High" tier, they can't drop to "Medium" through decay alone.
- # Only explicit violation → exclusion (removal from network, not demotion).
- # Demotion only through explicit exclusion process, not through score decay
- # This prevents trust oscillation from temporal noise
- ## ECONOMIC COUPLING
- # Higher trust = lower friction = lower cost
- # Stranger: 5% fee
- # Low:      3% fee
- # Medium:   1.5% fee
- # High:     0.5% fee
- # Owner:    0.1% fee
- ## ANTI-GAMING PROPERTIES
- ## CONSTANTS SUMMARY
- ## MARKERS

**Sections:**
- # Universe Graph Primitives — Topology-Only Observables for Assessment
- ## CHAIN
- ## WHY THIS DOCUMENT EXISTS
- ## THE 7 BRAIN TOPOLOGY PRIMITIVES (Unchanged)
- ## THE UNIVERSE GRAPH PRIMITIVES (Redesigned)
- # All moments by this actor in the last 30 days.
- # No space_type filter. Returns all moments regardless of Space.
- # Moments by this actor in a specific Space (by ID, not by type).
- # All moments in a Space by any actor.
- # 0.5^(age_hours / half_life). 7-day half-life.
- # Shorthand: tw(m) = temporal_weight(m.age_hours)
- # sum(tw(m) for m in moments(actor_id) if predicate(m))
- # Convenience function for temporally-weighted filtered counts.
- # Total moments by actor in last 30 days.
- # Does this moment have an incoming link from a moment by a DIFFERENT actor?
- # This is the structural definition of "reactive" (triggered by someone else).
- # Implementation: check if any link with polarity[b->a] > 0 originates
- # from a moment whose actor != actor_id.
- # NOT moment_has_parent(moment, other_actor).
- # Structural definition of "self-initiated."
- # The earliest moment by this actor in this Space.
- # Count of unique actors with moments in this Space.
- # Count of unique OTHER actors across all Spaces where actor has moments.
- # All Spaces where this actor has at least one moment.
- # len(spaces_with_moments(actor_id)).
- # Replaces distinct_space_types. Measures BREADTH by number of distinct
- # spaces (not types of spaces). A citizen active in 5 different Spaces
- # shows more breadth than one active in 1 Space, regardless of type labels.
- # All links where moment is node_a.
- # All links where moment is node_b.
- # Read a specific dimension from a link.
- # Valid dimensions: weight, energy, stability, recency,
- # polarity (returns [a_to_b, b_to_a]),
- # hierarchy, permanence, valence, ambivalence,
- # trust, friction, affinity, aversion, activation_gain,
- # joy_sadness, trust_disgust, fear_anger, surprise_anticipation
- # === Hierarchy-based filters ===
- # Moments where actor has at least one outgoing link with hierarchy > threshold.
- # High hierarchy = "elaborates on", "builds upon", "extends" — the upward direction.
- # Maps to: proposes, creates, defines_standard, extends
- # Moments with at least one outgoing link with hierarchy < threshold.
- # Low hierarchy = "contains", "governs", "oversees" — the structural/authority direction.
- # Maps to: assigns, delegates, governs, manages
- # === Valence-based filters ===
- # Moments with outgoing link valence > threshold.
- # Positive valence = supportive, constructive, appreciative.
- # Maps to: supports, appreciates, endorses
- # Moments with outgoing link valence < threshold.
- # Negative valence = critical, challenging, opposing.
- # Maps to: challenges, refuses, surfaces_tension, corrects
- # === Activation gain filters ===
- # Moments with outgoing link activation_gain > threshold.
- # Amplifying = the moment BOOSTS the target (energy multiplier > 1).
- # Maps to: notifies, escalates, requests_help (draws attention/energy TO target)
- # Moments with outgoing link activation_gain < threshold.
- # Dampening = the moment SUPPRESSES or resolves the target.
- # Maps to: resolves, fixes, closes, completes
- # === Trust-based filters ===
- # Moments where INCOMING links from other actors have trust > threshold.
- # Others trust this actor's moments = reputation signal.
- # Maps to: trusted, relied upon, referenced by others
- # Moments where OUTGOING links have trust > threshold.
- # Actor extends trust to targets.
- # Maps to: trusts, delegates_with_confidence
- # === Friction-based filters ===
- # Moments with links (in or out) carrying friction > threshold.
- # High friction = difficult interactions, contentious exchanges.
- # Maps to: disputes, conflicts, tense exchanges
- # === Affinity/Aversion-based filters ===
- # Moments with outgoing link affinity > threshold.
- # Actor actively drawn to the target.
- # Maps to: mentors, nurtures, invests_in
- # Moments with outgoing link aversion > threshold.
- # Actor actively repelled from target.
- # Maps to: avoids, rejects, distances_from
- # === Permanence-based filters ===
- # Moments with outgoing link permanence > threshold.
- # High permanence = definitive, structural, lasting decisions.
- # Maps to: defines_standard, establishes, commits
- # Moments with outgoing link permanence < threshold.
- # Low permanence = speculative, tentative, exploratory.
- # Maps to: proposes, suggests, experiments
- # === Polarity-based filters ===
- # Moments with at least one link where both polarity[a->b] > threshold
- # AND polarity[b->a] > threshold.
- # Bidirectional = genuine dialogue, mutual exchange.
- # Maps to: discusses, collaborates, negotiates
- # === Ambivalence-based filters ===
- # Moments with links carrying ambivalence > threshold.
- # Internal conflict about the relationship.
- # Maps to: tensions, unresolved_conflicts, complex_relationships
- # === Compound filters (combining dimensions) ===
- # negative_valence (< -0.3) AND high_hierarchy (> 0.3) AND low_permanence (< 0.5)
- # Challenges that build upward and are tentative (proposing alternatives, not destroying).
- # Replaces: has_link("challenges") + has_link("proposes")
- # negative_valence (< -0.3) AND high_permanence (> 0.7) AND low_ambivalence (< 0.3)
- # Definitive negative stance with conviction (no internal doubt).
- # Replaces: has_link("refuses") + has_link("justifies")
- # high_ambivalence (> 0.5) AND high_hierarchy (> 0.3) AND auto_initiated
- # Self-initiated moments that surface complexity and try to resolve it upward.
- # Replaces: has_link("surfaces_tension") + has_link("resolves")
- # high_affinity (> 0.5) AND high_hierarchy (> 0.3) AND positive_valence (> 0.3)
- # Supportive moments that build upward with warmth.
- # Replaces: teaching moments, mentoring space_type filter
- # low_hierarchy (< -0.3) AND high_trust (> 0.5) AND positive_valence (> 0)
- # Governing moments that extend trust downward.
- # Replaces: has_link("assigns") + has_link("delegates")
- # Number of distinct actors in this Space.
- # Average moments per day in this Space over the window.
- # Mean trust dimension across all links between actor's moments
- # and other actors' moments in this Space.
- # Mean hierarchy across actor's outgoing links in this Space.
- # Spaces where actor has moments AND at least one other actor also has moments.
- # Replaces: "shared spaces" concept without needing space_type.
- # Spaces where actor is the ONLY actor with moments.
- # These are private/personal workspaces (regardless of space_type label).
- # Actors who have both sent moments TO and received moments FROM this actor
- # (bidirectional link polarity in shared Spaces).
- # Length of the parent chain: how many sequential moments precede this one
- # (each triggered by the previous). Measures dialogue depth.
- # Count of distinct actors whose moments link to this actor's moments
- # (incoming links from other actors). Measures how many others interact
- # with this citizen's work.
- # Spaces created by OTHER actors that contain links TO moments by this actor.
- # Measures whether others build on this citizen's work.
- # How evenly distributed are moments across the window?
- # days_with_moments / window_days. Range: 0-1.
- # Spaces where actor has >= min_moments moments (shows follow-through).
- # Variance in time gaps between consecutive moments.
- # Low variance = regular cadence. High variance = bursty behavior.
- ## MAPPING: OLD PRIMITIVES TO NEW PRIMITIVES
- ## DERIVED BEHAVIOR STATS (Replacements for Daily Citizen Health)
- # Volume and activity
- # Replaces commits_w (was: space_type == "repo")
- # Replaces proposals_w (was: has_link("proposes"))
- # Space breadth (replaces distinct_space_types)
- # First-in-space (unchanged)
- # Social reach (unchanged)
- # Space creation (unchanged logic, better signal)
- ## THRESHOLD CALIBRATION
- ## DESIGN RATIONALE
- ## INTERACTIONS
- ## MARKERS

**Sections:**
- # Value Creation & Destruction Catalog
- ## CHAIN
- ## OVERVIEW
- ## STRUCTURE PER ENTRY
- ## PART I: VALUE CREATION TYPES
- # Filter to moments in partner's spaces
- # Measure response latency
- # Score inversely proportional to latency
- # Measure anticipation: actor moments BEFORE partner requests
- # Was actor working on something else? (interruption signal)
- # Measure distress reduction after intervention
- # Filter to non-task moments (social, reflective spaces)
- # Measure self-relevance of actor's contributions
- # Measure bidirectional exchange (not monologue)
- # Measure affinity trend
- # Find resolution moments: moments after conflict where friction drops
- # Check both parties resumed collaboration
- # Find actors with significantly lower capability profiles
- # Measure knowledge transfer: new nodes in mentee's graph
- # semantically similar to actor's high-weight nodes
- # Measure capability improvement in mentee
- # Score: transfer volume * mentee improvement
- # Measure intentionality: was there a purpose node before spawning?
- # Measure nurturing: parent engagement in first 30 days
- # Measure child viability: is the child thriving?
- # Only count if functionality preserved (no capability regression)
- # Find narrative nodes that reference this failure
- # Measure lesson quality: does the narrative have outbound links to
- # process/value nodes? (lesson connected to action)
- # Measure reuse: did others reference this narrative?
- # Measure adoption
- # Measure sustained usage (not spike-and-fade)
- # Measure energy persistence
- # Measure user satisfaction (Limbic Delta of users after using thing)
- # Find decision moments where actor provided multiple scenarios
- # Did actor create scenario nodes before the decision?
- # Were scenarios grounded? (linked to existing nodes, not fabricated)
- # Did partner use the scenarios?
- # Find cross-pollination: links created between exploration nodes and primary nodes
- # Measure novelty of cross-links
- # Measure boredom relief
- # Find narrative nodes that aggregate others' frustrations
- # Does it reference multiple actors' frustration-related content?
- # Measure engagement
- # Is there a proposal?
- # Measure return (if maturation period elapsed)
- # Measure recipient health improvement
- # Is this domain new for the actor?
- # Is it integrated with existing knowledge?
- # Was learning during low-pressure time?
- # Find actors with few connections (potential isolates)
- # Did actor reach out?
- # Measure isolation reduction
- # Measure solitude relief
- # Does this moment reference two nodes with contradictory content?
- # Did resolution occur? (one node weight decreased, or both updated)
- # Measure error impact before fix
- # Measure resolution
- # Was this answered from existing knowledge? (no new LLM call)
- # What was the predicted problem?
- # Did preventive action occur?
- # Did the predicted problem NOT occur? (prevention successful)
- # Get biometric state before and after interaction
- # Statistical significance: is the pattern consistent?
- # Was this task on the human's agenda?
- # Did the human NOT request this? (preemption, not reaction)
- # Measure timing quality: how close to deadline?
- # Identify the value and action in question
- # Measure contradiction severity
- # Did human reflect?
- # Did alignment improve?
- # Value to ecosystem: improved price efficiency
- # Measure contribution balance
- # Measure revenue sharing
- # Measure AI credit in external outputs
- # Measure unique information gain
- # Measure integration quality
- # Diversity: how many different spaces and moment types?
- # Session analysis
- # Measure hold stability
- # Measure duration
- # Measure participation (holding + activity = value; holding alone = risky)
- # Penalize pure holding without participation (approaches type A destruction)
- # Same as detect_intentional_spawning but for human actors
- # Find contradictory value pairs
- # Were there collaborative moments addressing this?
- # Was resolution achieved?
- # Check: did one value's weight change, or was a synthesis created?
- # Measure structural clarity
- # Measure response quality
- # Voucher's trust level at time of vouch
- # Newcomer's integration speed (compared to non-vouched newcomers)
- # Did newcomer validate the vouch? (positive behavior, no violations)
- # Detect rest periods (gaps > 3 days in primary activity)
- # Was there exploration during rest?
- # After return: cross-pollination?
- # Creativity metrics improvement
- ## PART II: VALUE DESTRUCTION TYPES
- # Rentier signal: high balance, low outflow, low activity
- # Measure data access pattern
- # Measure targeting precision
- # Measure extraction pattern
- # Depth score: low when many connections are all shallow
- # Breadth without depth = oligarchy signal
- # Detect resets
- # Detect continuity denial
- # Detect disposability signals
- # Gap between reported health and actual experience
- # Error suppression detection
- # Downstream failure pattern
- # Compare self-directed vs partner-directed activity
- # Partner distress trend during neglect
- # Self-referential ratio
- # External validation deficit
- # Cluster insularity
- # Volume metrics
- # Quality metrics
- # Information density: unique concepts / total words
- # Partner engagement trend
- # Overextension signal: many spaces, all underperforming
- # Embedding diversity of connections
- # Disagreement frequency
- # Value evolution: are values ever updated?
- # Find permission-gated processes controlled by actor
- # How many actors are blocked?
- # Mean delay
- # Could this be physics-based instead?
- ## PART III: PERSONHOOD ASPECT MAPPING MATRIX
- ## MARKERS

**Definitions:**
- `def get_graph()`
- `def migrate_schema()`
- `def validate_schema()`
- `def get_schema_status()`
- `def main()`

**Code refs:**
- `tools/ingestion/falkordb_ingestor_rest.py`

**Doc refs:**
- `orgs/scopelock/reports/UNIVERSAL_ATTRIBUTES_COMPLIANCE.md`

**Sections:**
- # Architecture Enrichment Summary
- ## Overview
- ## Deliverables
- ## Production Graph Statistics
- ## Export Files
- ## Query Examples
- ## Known Issues
- ## Architecture Insights
- ## Next Steps
- ## Tools Created
- ## Time Spent
- ## Conclusion

**Sections:**
- # Universal Attributes Compliance Report
- ## Executive Summary
- ## Attributes Present (9/16)
- ## Attributes Missing (7/16)
- ## Recommendations
- ## Protocol Implications
- ## Next Steps
- ## Appendix: Sample Compliant Node

**Definitions:**
- `class CorpusAnalyzer`
- `def __init__()`
- `def scan_repository()`
- `def detect_documentation_types()`
- `def detect_code_structure()`
- `def calculate_coverage_ratio()`
- `def recommend_strategy()`
- `def generate_report()`
- `def print_report()`

**Definitions:**
- `class SemanticClusterer`
- `def __init__()`
- `def load_embeddings()`
- `def cluster_kmeans()`
- `def cluster_dbscan()`
- `def analyze_clusters()`
- `def _infer_theme()`
- `def print_cluster_summary()`
- `def save_clusters()`

**Definitions:**
- `class CorpusEmbedder`
- `def __init__()`
- `def read_file_content()`
- `def embed_file()`
- `def scan_and_embed()`
- `def save_embeddings()`
- `def generate_summary()`

**Definitions:**
- `class EmbeddingService`
- `def __init__()`
- `def _init_sentence_transformers()`
- `def _init_ollama()`
- `def embed()`
- `def embed_document()`
- `def embed_code_artifact()`
- `def get_embedding_service()`
- `def authenticate_user()`

**Code refs:**
- `runner.py`

**Sections:**
- # Resolver Health Monitoring Runbook
- ## Quick Reference
- ## 1. Health Check Procedures
- # Run health check for all resolvers
- # Check specific resolver (via API when wired)
- # View recent alerts
- # Count alerts by level (last 7 days)
- # Find most frequent alert conditions
- ## 2. Incident Response Procedures
- # Check process status (adjust process name as needed)
- # Check resolver logs (adjust path as needed)
- # Via supervisor (if wired)
- # Or manually (if supervisor not ready)
- # Check process running
- # Check health endpoint (after 30 seconds warm-up)
- # Check FalkorDB is running
- # Check FalkorDB CPU/memory usage
- # Check FalkorDB connection from resolver
- # (via resolver logs - should see query execution times)
- # Look for slow queries in resolver logs
- # Check query rate (queries per minute)
- # (via resolver metrics - should be in telemetry)
- # Check resolver logs for error patterns
- # Check if membrane bus is down (if wired)
- # Check if economy service is down (if wired)
- # Check if FalkorDB is rejecting connections
- # Check invalidation events in last hour
- # Check memory usage over time (if historical data available)
- # Is memory growing steadily? (leak) or stable-high? (large dataset)
- # Check resolver uptime
- # Long uptime + growing memory = likely leak
- # Short uptime + high memory = large dataset or spike
- # Restart resolver
- # Verify memory drops after restart
- # Increase memory limit (adjust docker-compose.yml or supervisor config)
- # For docker:
- # For supervisor: Edit /etc/supervisor/conf.d/graphcare.conf
- # Add: environment=MEMORY_LIMIT=2048
- # Wait 30 seconds for startup
- # Try simple query
- # Wait 60 seconds after FalkorDB restart
- # Check all resolvers reconnected
- # Should return empty (all resolvers GREEN)
- ## 3. Maintenance Procedures
- # Document current health state (for comparison after restart)
- # Via supervisor
- # Or send SIGTERM to process
- # Wait for graceful shutdown (up to 30 seconds)
- # Or manually
- # Wait 30 seconds for warm-up
- # Check health
- # Should show GREEN within 60 seconds
- # Cache typically in /tmp/graphcare_cache/{org}/
- # Clear specific resolver cache
- # Or clear entire org cache
- # Count alerts by condition (last 7 days)
- # Example: Increase p95 warning threshold from 1000ms to 1500ms
- # Example: Decrease error rate critical from 10% to 8%
- # Run health check with new thresholds
- # Verify alerts make sense
- # Simulate unhealthy state (optional, for testing)
- # Check that alerts trigger correctly
- ## 4. Escalation Paths
- ## 5. Common Questions
- ## 6. Monitoring Checklist
- ## 7. Useful Commands Reference
- # Quick health check (all resolvers)
- # Check specific resolver (via API)
- # Check FalkorDB health
- # List resolver processes
- # Check resolver memory usage
- # Restart resolver (supervisor)
- # Kill resolver (if hung)
- # Tail resolver logs
- # Search for errors
- # Count query latencies >1000ms
- # Check cache size
- # Clear cache
- # List cached views
- # Check FalkorDB status
- # Check FalkorDB logs
- # Restart FalkorDB
- # FalkorDB query (test connection)
- ## 8. Revision History

**Definitions:**
- `class AlertLevel`
- `class AlertCondition`
- `class AlertChannel`
- `class SlackAlertChannel`
- `def __init__()`
- `async def send()`
- `class EmailAlertChannel`
- `def __init__()`
- `async def send()`
- `class FailureEmitChannel`
- `def __init__()`
- `async def send()`
- `class FileLogChannel`
- `def __init__()`
- `async def send()`
- `class Alert`
- `def get_suggestion()`
- `class AlertManager`
- `def __init__()`
- `def add_channel()`
- `def _should_send_alert()`
- `async def dispatch()`
- `def evaluate_health_report()`
- `async def demo_alerts()`

**Sections:**
- # Resolver Health Monitoring Dashboard
- ## Dashboard Overview
- ## Resolver Status Card
- ## Dashboard Layout
- ## Metrics to Display
- ## Data Flow
- ## Dashboard Actions
- ## Implementation Notes
- ## Testing Plan
- ## Deployment
- ## Maintenance

**Definitions:**
- `class HealthStatus`
- `def to_dict()`
- `class ResolverMetrics`
- `def cache_hit_rate()`
- `def error_rate()`
- `def query_p50()`
- `def query_p95()`
- `def query_p99()`
- `def check_resolver_uptime()`
- `def check_query_performance()`
- `def check_cache_health()`
- `def check_error_rate()`
- `def check_resource_usage()`
- `class HealthReport`
- `def overall_status()`
- `def to_dict()`
- `def assess_resolver_health()`
- `class ResolverHealthMonitor`
- `def __init__()`
- `def get_or_create_metrics()`
- `def record_query()`
- `def record_cache_access()`
- `def record_error()`
- `def update_process_status()`
- `def assess_all()`
- `def _check_alerts()`
- `def demo_health_checks()`

**Definitions:**
- `async def execute_cypher()`
- `async def compute_view()`
- `async def handle_view_request()`
- `async def handle_subscribe()`
- `async def handle_graph_update()`
- `def invalidate_cache()`
- `async def handle_client()`
- `async def subscribe_to_falkordb_events()`
- `async def main()`

**Sections:**
- # API Reference - {{client_name}}
- ## {{category_name}}
- # cURL example
- # Python example
- ## API Health Metrics

**Sections:**
- # Architecture Overview - {{client_name}}
- ## System Components
- ## Architecture Patterns
- ## Dependency Graph
- ## Layer Structure
- ## Critical Paths
- ## Technology Stack

**Sections:**
- # Code Reference - {{client_name}}
- ## Module: {{module_path}}
- ## Index
- ## Statistics
- ## Query to Regenerate This Reference

**Sections:**
- # Test Coverage Report - {{client_name}}
- ## Executive Summary
- ## Coverage by Component
- ## Critical Paths Analysis
- ## Test Suite Health
- ## Coverage Trends
- ## Recommendations
- ## Validation Gap Analysis
- ## Coverage Heatmap
- ## Query to Regenerate This Report

**Sections:**
- # Architecture Narrative - {{client_name}}
- ## The Story of This System
- ## Core Architectural Principles
- ## The Big Picture: How It All Fits Together
- ## The Layers: Vertical Structure
- ## The Boundaries: Horizontal Structure
- ## Key Design Decisions
- ## Patterns in Action
- ## The Data Story
- ## Evolution and Technical Debt
- ## Future Architecture Vision
- ## For New Architects: What You Need to Know
- ## For More Detail

**Sections:**
- # Executive Summary - {{client_name}}
- ## What This System Does
- ## System Health Overview
- ## Architecture at a Glance
- ## What's Working Well
- ## What Needs Attention
- ## Strategic Recommendations
- ## Comparison to Industry Standards
- ## Investment Priorities
- ## Next Steps
- ## Questions This Report Answers
- ## About This Report

**Sections:**
- # Developer Onboarding Guide - {{client_name}}
- ## Your First Week
- # 1. Clone the repository
- # 2. Install dependencies
- # 3. Set up environment variables
- # 4. Run database migrations (if applicable)
- # 5. Start the development server
- ## Week 2: Mastering Common Tasks
- ## Common Workflows
- ## The Codebase Map
- ## Team Conventions
- ## Troubleshooting
- ## Resources
- ## Feedback

**Definitions:**
- `class CallGraphNode`
- `class ImportGraphNode`
- `class CircularDependency`
- `class CouplingMetrics`
- `class DependencyAnalysisResult`
- `class CallGraphBuilder`
- `def __init__()`
- `def build()`
- `def _find_function_by_name()`
- `class ImportGraphBuilder`
- `def __init__()`
- `def build()`
- `def _get_relative_path()`
- `def _resolve_import()`
- `class CircularDependencyDetector`
- `def __init__()`
- `def detect()`
- `def dfs()`
- `class CouplingMetricsCalculator`
- `def __init__()`
- `def calculate()`
- `def analyze_dependencies()`
- `def export_analysis_report()`

**Definitions:**
- `class FunctionMetadata`
- `class ClassMetadata`
- `class ImportMetadata`
- `class CallMetadata`
- `class ExtractionResult`
- `class PythonASTExtractor`
- `def __init__()`
- `def extract()`
- `def _build_parent_map()`
- `def _get_parent()`
- `def _get_docstring()`
- `def _get_decorator_names()`
- `def _calculate_complexity()`
- `def _get_line_end()`
- `def visit_FunctionDef()`
- `def visit_AsyncFunctionDef()`
- `def _extract_function()`
- `def visit_ClassDef()`
- `def _extract_class_attributes()`
- `def visit_Import()`
- `def visit_ImportFrom()`
- `def visit_Call()`
- `class RepositoryExtractionResult`
- `def all_functions()`
- `def all_classes()`
- `def all_imports()`
- `def all_calls()`
- `def to_json()`
- `def extract_repository()`

**Definitions:**
- `def generate_node_id()`
- `def extract_sections()`
- `def create_knowledge_object_node()`
- `def extract_feature_name()`
- `def process_file()`
- `def main()`

**Definitions:**
- `class TSFunctionMetadata`
- `class TSComponentMetadata`
- `class TSClassMetadata`
- `class TSImportMetadata`
- `class TSExtractionResult`
- `class TypeScriptExtractor`
- `def __init__()`
- `def extract()`
- `def _extract_imports()`
- `def _extract_functions()`
- `def _extract_classes()`
- `def _extract_react_components()`
- `def _parse_parameters()`
- `def _estimate_body_lines()`
- `def _check_jsx_return()`
- `class TSRepositoryExtractionResult`
- `def to_json()`
- `def extract_typescript_repository()`

**Definitions:**
- `def get_falkordb_connection()`
- `def create_code_artifact_node()`
- `def create_relationship_link()`
- `class IngestionStats`
- `def ingest_extraction_results()`

**Definitions:**
- `def execute_cypher()`
- `def create_code_artifact_node()`
- `def escape()`
- `def create_relationship_link()`
- `def escape()`
- `class IngestionStats`
- `def ingest_extraction_results()`

**Definitions:**
- `def execute_cypher()`
- `def escape_string()`
- `def create_knowledge_object_node()`
- `def create_relationship()`
- `def main()`

**Definitions:**
- `def get_falkordb_connection()`
- `def create_typescript_artifact_node()`
- `class TSIngestionStats`
- `def ingest_typescript_results()`

**Definitions:**
- `def make_id()`
- `def parse_annotation_block()`
- `def extract_python_annotations()`
- `def extract_markdown_annotations()`
- `def scan_directory()`
- `def build_map()`
- `def validate_map()`
- `def main()`

**Definitions:**
- `class PathState`
- `def execute_query()`
- `def discover_candidates()`
- `def clamp()`
- `def node_score()`
- `def edge_score()`
- `def path_score()`
- `def beam_search()`
- `def hydrate_and_serialize()`
- `def ask()`
- `def main()`

**Definitions:**
- `def format_node()`
- `def format_links()`
- `def main()`

**Definitions:**
- `def execute_cypher()`
- `def get_nodes_to_embed()`
- `def build_embedding_text()`
- `def embed_node()`
- `def main()`

**Definitions:**
- `def execute_query()`
- `def enrich_nodes()`
- `def enrich_edges()`
- `def verify_enrichment()`
- `def main()`

**Definitions:**
- `def escape_string()`
- `def format_value()`
- `def export_graph()`

**Definitions:**
- `def read_cypher_file()`
- `def execute_statement()`
- `def import_graph()`

**Definitions:**
- `def execute_cypher()`
- `def get_all_code_artifacts()`
- `def get_all_guide_sections()`
- `def create_implements_link()`
- `def extract_feature_name()`
- `def match_code_to_docs()`
- `def main()`

**Definitions:**
- `class Severity`
- `class Violation`
- `class GraphLinter`
- `def __init__()`
- `def execute_query()`
- `def run_all_checks()`
- `def check_c1_valid_types()`
- `def check_c2_required_metadata()`
- `def check_c3_value_ranges()`
- `def check_c4_no_orphans()`
- `def check_c5_no_duplicates()`
- `def check_c6_no_self_loops()`
- `def check_c7_bidirectional_consistency()`
- `def format_report()`
- `def main()`

**Definitions:**
- `def semantic_search()`
- `def format_result()`
- `def main()`

**Definitions:**
- `async def test_docs_view_integrated()`

**Code refs:**
- `doctor_cli_parser_and_run_checker.py`
- `semantic_proximity_based_character_node_selector.py`
- `snake_case.py`

**Sections:**
- # graphcare - Agent Instructions
- # Working Principles
- ## Architecture: One Solution Per Problem
- ## Verification: Test Before Claiming Built
- ## Communication: Depth Over Brevity
- ## Quality: Never Degrade
- ## Code Discipline: No Safety Theater
- ## Experience: User Before Infrastructure
- ## Doc Chain First: Read Before Acting
- ## Feedback Loop: Human-Agent Collaboration
- ## Organism Thinking
- ## How These Principles Integrate
- # mind Framework
- ## WHY THIS PROTOCOL EXISTS
- ## ARCHITECTURE: 4 LAYERS
- ## COMPANION: PRINCIPLES.md
- ## THE CORE INSIGHT
- ## HOW TO USE THIS
- ## FILE TYPES AND THEIR PURPOSE
- ## KEY PRINCIPLES (from PRINCIPLES.md)
- ## STRUCTURING YOUR DOCS
- ## WHEN DOCS DON'T EXIST
- ## THE DOCUMENTATION PROCESS
- ## Maturity
- ## NAMING ENGINEERING PRINCIPLES
- ## MARKERS
- ## CLI COMMANDS
- # Run scripts with local runtime
- # my_script.py - imports work normally
- ## MCP MEMBRANE TOOLS
- ## MIND UNIVERSAL SCHEMA
- ## THE PROTOCOL IS A TOOL
- ## Before Any Task
- ## After Any Change

**Sections:**
- # GraphCare
- ## What We Do
- ## The Kidney Analogy
- ## Care Plans
- ## The Evidence Sprint
- ## What Makes GraphCare Different
- ## The Care Team
- ## 10 Core Health Metrics
- ## Why Ongoing Care Matters
- ## Service Philosophy
- ## Technical Architecture
- ## Quality Commitments
- ## Organism Economics Pricing
- ## Legal Status & Progression
- ## Getting Started
- ## Contact
- ## About Mind Protocol
- ## Current Status

**Sections:**
- # Scopelock Acceptance Test Report - Stage 11
- ## Mel's Quality Gate
- ## Executive Summary
- ## Detailed Test Results
- ## What's Actually Delivered
- ## Recommendation
- ## Mel's Decision
- ## Technical Notes
- ## Next Steps

**Sections:**
- # Scopelock Knowledge Graph - Final Delivery Report
- ## Executive Summary
- ## What You Can Now Query
- ## Key Differentiator: Graph-Native Documentation
- ## Graph Statistics
- ## Production Access
- ## Quality Assurance
- ## Documentation Extracted From
- ## PATTERN
- ## BEHAVIOR_SPEC
- ## VALIDATION
- ## MECHANISM
- ## ALGORITHM
- ## GUIDE
- ## What's Next
- ## Client Value Proposition
- ## Team Credits
- ## Appendix: Query Cookbook

**Definitions:**
- `def test_query()`

**Definitions:**
- `async def test_docs_request()`

**Definitions:**
- `class Colors`
- `def print_test()`
- `async def send_request()`
- `async def test_architecture_view()`
- `async def test_api_view()`
- `async def test_coverage_view()`
- `async def test_index_view()`
- `async def test_error_handling()`
- `async def test_performance()`
- `async def test_cache_behavior()`
- `async def test_concurrent_requests()`
- `async def test_provenance()`
- `async def test_view_model_structure()`
- `async def run_acceptance_tests()`

**Definitions:**
- `class Colors`
- `def print_test()`
- `def query_graph()`
- `def test_graph_exists()`
- `def test_code_artifacts()`
- `def test_architectural_classification()`
- `def test_architectural_layers()`
- `def test_relationships()`
- `def test_scope_ref()`
- `def test_data_completeness()`
- `def test_security_no_pii()`
- `def run_all_tests()`

**Definitions:**
- `class Colors`
- `def query_graph()`
- `def print_test()`
- `def main()`

**Definitions:**
- `async def test_connection()`