A AisOpsFlow Enterprise Docs Official product documentation and user manual

public-private-boundary

Public / Private Boundary (Current Codebase)

This document classifies the current repository into:

  • keep private
  • make public
  • split/refactor before publishing

The goal is to support an open plugin ecosystem while protecting the commercial control plane.

Keep private

These contain product differentiation, operational internals, or deployment-sensitive logic.

Runtime product

  • core/
    • private except for any future extracted SDK/spec artifacts
  • runner/
    • private runtime executable

Private implementation modules

Storage and backend adapters

  • core/src/AisOpsFlow/DB/
  • core/src/AisOpsFlow/Beam/
  • core/src/AisOpsFlow/DB.hs

Reason:

  • schema and migration code may stay private if the product is delivered as images
  • backend abstraction is runtime internals, not plugin extension surface

Deployment and ops packaging

  • deploy/
  • production-oriented scripts/
  • internal CI/CD workflows when added

Reason:

  • these expose operational assumptions and commercial packaging choices

Good candidates to make public

These are part of the extension surface or can become it with minimal cleanup.

Plugin examples

These should move to a public SDK/examples repo.

Shared plugin helper

This is a strong seed for a public plugin helper package.

Public-facing contract docs

These need a public edit pass, but they are the right starting point.

Split before publishing

These are useful externally, but current form is too coupled to private internals.

1. Plugin contract spec

Current source is implicit in:

  • plugin example implementations
  • runner request behavior
  • internal auth helpers

Needs extraction into:

  • docs/plugin-api-v1.md
  • JSON schemas
  • compatibility/versioning rules

2. Internal auth helper

Current code exists in several private/public places:

Public target should be:

  • language-neutral signing spec
  • official helpers for Node and Python

Do not publish the Haskell internal modules directly as the SDK story.

3. Plugin conformance suite

Current repo has useful verification scripts, but they are product-level.

Public target should be:

  • plugin-focused contract tests
  • no dependency on private control-plane internals

4. Protobuf and runner-plugin separation docs

  • proto/ can stay private if Core↔︎Runner remains proprietary
  • Runner↔︎Plugin contract should be documented separately and publicly

Recommendation:

  • keep proto/core_runner/v1 private
  • publish Runner↔︎Plugin HTTP/JSON contract only

Suggested public repo contents

Repo: aisopsflow-plugin-sdk

  • examples/node/
  • examples/python/
  • schemas/
  • docs/plugin-api-v1.md
  • docs/publishing.md
  • docs/security-signing.md
  • packages/js/internal-auth/
  • packages/python/internal_auth/
  • tests/conformance/

Repo: aisopsflow-plugin-catalog

  • plugins/<publisher>/<plugin>/manifest.yaml
  • compatibility/
  • verification/

Suggested private repo contents

  • core/
  • runner/
  • proto/
  • deploy/
  • production scripts
  • internal integration tests

Immediate extraction candidates from the current tree

If you start the split now, extract in this order:

  1. plugins/shared/internal-auth.js
  2. plugins/channel-*
  3. plugins/kakao-provider-mock
  4. plugin API docs from docs/content/product/spec-v0.1.md
  5. public conformance test kit

Not ready to publish as-is

  • core/src/AisOpsFlow/Validation.hs
  • core/src/AisOpsFlow/Web.hs
  • core/src/AisOpsFlow/App/*
  • core/src/AisOpsFlow/Workflow/*

Reason:

  • these are product internals, not extension API
  • publishing them creates maintenance burden without helping plugin authors much