Noosphere Engine: Cross-PR Integration Concerns

[user1303836]

Cross-PR Integration Summary

PRs #187 (foundation), #188 (analytics), and #189 (features) each pass their own test suites but have integration seams that will break at runtime when merged together. This issue tracks those cross-cutting concerns.

---

1. Event Dispatch Signature Mismatch (Critical)

Producer (PR #189 engine.py:60-65):

self.bot.dispatch(
    "state_vector_updated",
    guild_id=self.guild_id,
    mode_weights=mode_weights,
    tick_count=self._tick_count,
)

Consumers (PR #188 -- resonance_mirror, attractor_dashboard, cryptobiosis, pathology_cog):

@commands.Cog.listener("on_state_vector_updated")
async def _on_state_vector(self, csv: CommunityStateVector) -> None:

The engine dispatches keyword args; the listeners expect a single CommunityStateVector positional arg. Discord.py will call the listener with the kwargs, causing a TypeError at runtime. Every Phase 2 cog that listens on this event will fail silently (discord.py swallows listener exceptions by default).

Same mismatch exists for message_processed -- the engine dispatches keyword args but Phase 2 cogs expect a ProcessedMessage object.

Resolution: The engine must construct actual CommunityStateVector and ProcessedMessage objects and dispatch them as positional args. This requires the engine to import from shared/data_models.py (the canonical shared models from PR #187).

---

2. Discord ID Type: str vs int (All 3 PRs)

The existing codebase uses str for all Discord IDs:

• DB columns: String(36) in database/models.py
• Repository methods: all accept str
• Cogs: convert with str(interaction.guild_id) at boundary

All 3 Noosphere PRs use int internally. This creates a type mismatch at every boundary where Noosphere code interacts with existing code (database queries, cross-cog communication, event payloads).

Affected locations:

• PR Add Noosphere Engine foundation (Phase 0 + Phase 1) #187: CommunityStateVector.guild_id: int, ProcessedMessage.guild_id/channel_id/user_id: int, MetricsComputer dicts keyed by int
• PR Phase 2: Noosphere Engine analytics modules #188: All cog dicts keyed by int, CordycepsReport counts keyed by int, UserState.user_id: int, MorphogeneticField.guild_id: int
• PR Add Noosphere Engine: Phase 3 features and orchestrator #189: NoosphereEngine.guild_id: int, CrystalRoomInfo all IDs int, ModeManager.guild_id: int, NoosphereCog.engines: dict[int, ...]

Resolution: Change to str throughout. The canonical ProcessedMessage and CommunityStateVector in shared/data_models.py (PR #187) define the contract; PRs #188 and #189 must follow.

---

3. Enum Base Class: enum.Enum vs str, enum.Enum (PRs #187, #188)

PR #189 correctly uses str, enum.Enum. PRs #187 and #188 use bare enum.Enum. When these enums are serialized (JSON logging, event payloads, database storage), bare enum.Enum values won't serialize cleanly without .value access.

Affected:

• PR Add Noosphere Engine foundation (Phase 0 + Phase 1) #187: ComputationMode, PathologyType, MessageClassification
• PR Phase 2: Noosphere Engine analytics modules #188: CryptobiosisState, PathologyType (local duplicate)

Resolution: All enums use str, enum.Enum. PR #187's constants.py is the canonical source.

---

4. Shared Models Divergence (PR #188)

PR #188 ships its own shared/models.py with divergent field types:

• int IDs (should be str)
• list[float] embeddings (should be np.ndarray | None)
• Bare str classification (should be MessageClassification enum)

PR #187's shared/data_models.py is the agreed canonical source.

Resolution: PR #188 deletes shared/models.py and imports from shared/data_models.py. All downstream code adapts to the canonical types.

---

5. Duplicate Constants/Enums Across PRs

• PR Add Noosphere Engine foundation (Phase 0 + Phase 1) #187 defines PathologyType in constants.py (10 Godelian pathologies: CANCER, CYTOKINE_STORM, etc.)
• PR Phase 2: Noosphere Engine analytics modules #188 defines its own PathologyType in pathology.py (5 community pathologies: ECHO_CHAMBER, BOT_DOMINANCE, etc.)
• PR Add Noosphere Engine: Phase 3 features and orchestrator #189 defines PathologyType in constants.py (same 10 as Add Noosphere Engine foundation (Phase 0 + Phase 1) #187) plus CrystalRoomMode, CrystalRoomState, ComputationMode

These need to be consolidated into a single constants.py. The 10-mode Godelian taxonomy (PRs #187/#189) and the 5 community pathologies (PR #188) serve different purposes and should coexist as separate enums (e.g., GodelianPathology vs CommunityPathology), or PR #188's detectors should map to the Godelian taxonomy.

---

6. CommunityStateVector Missing Fields

PR #187's CommunityStateVector is missing fields that PR #188 consumers depend on:

• sentiment_alignment (used by detect_flame_war in pathology.py:94)
• interaction_modularity (used by detect_clique_formation in pathology.py:111, and displayed in attractor dashboard)

These must be added to the canonical dataclass with math.nan defaults (computable in later phases).

---

Merge Order Recommendation

1. PR Add Noosphere Engine foundation (Phase 0 + Phase 1) #187 first (foundation) -- defines canonical shared models, constants, enums
2. PR Phase 2: Noosphere Engine analytics modules #188 second (analytics) -- imports from foundation, adapts to canonical types
3. PR Add Noosphere Engine: Phase 3 features and orchestrator #189 third (features + engine) -- imports from foundation, constructs proper event payloads

Each PR should rebase onto the previous after merge to resolve any conflicts.

---

Cross-Reference

• PR Add Noosphere Engine foundation (Phase 0 + Phase 1) #187 review: Add Noosphere Engine foundation (Phase 0 + Phase 1) #187 (comment)
• PR Phase 2: Noosphere Engine analytics modules #188 review: Phase 2: Noosphere Engine analytics modules #188 (comment)
• PR Add Noosphere Engine: Phase 3 features and orchestrator #189 review: Add Noosphere Engine: Phase 3 features and orchestrator #189 (comment)