BPOS-TMP-REPO/apps/api/src/app/seed-activities.ts

/**
 * 真活动包的安装 —— **经安装通道读文件,不经代码通道**(ADR-004 / 编码规范 §5.1)。
 *
 * 活动包在系统外开发:`activities/<pkg>/` 里写清单与资产,`pnpm activities:build`
 * 产出 `dist/{manifest.json,index.js}`。api 只读这两个文件 —— 与 activities 之间
 * 只有安装通道,没有 import(depcruise 的 `apps-not-into-activities` 在守)。
 *
 * 这就是「系统外开发、安装即用」的机器形态:装的时候过两审(静态审读清单、
 * 回放审重演历史),清单里的台账声明顺带把表物化出来,资产随包播种。
 *
 * 装不上不掀翻播种:如实报出来。活动包是可选件 —— 没构建产物就是没装,
 * 不是数据库坏了(而假装装上了才是真的坏)。
 */
import { readFile } from 'node:fs/promises';
import { join, resolve } from 'node:path';
import { activityManifestSchema } from '@contracts';
import type { Container } from './container.ts';
import { MASTER_OBJECTS, MASTER_SAMPLE_ROWS } from './seed-mvp-data.ts';

/** 已开发完成、要随播种装上的真活动包(目录名 = 包目录,不是 activityId) */
/*
 * 真活动包 —— 从 `activities/<pkg>/dist/` 读文件装入,**不经 import**。
 * A2/A3 于 2026-07-31 转正:它们的案例模型已简化为「一张执行单办完」,
 * 剧本与 A1 同一套机制,不再是治理台里那两个 viewTemplates 为空的占位槽。
 */
/*
 * 2026-08-24 用户定:**只装 E04 / I01**,A1–A7 报价链六个包从系统里卸载(源码留着,
 * 只是不再播种、不再安装;库里已装的版本已置 uninstalled)。要装回来把名字加回这里
 * 再跑 activities:install 即可 —— 它们的 dist 照旧随 activities:build 产出。
 *   退役名单:quote-intake · quote-alternative · quote-sourcing · quote-pricing ·
 *             quote-negotiate · quote-archive
 */
const REAL_PACKAGES = ['crm-relationship-coverage', 'brand-content-toolkit'] as const;

/**
 * 活动包根目录。
 *
 * 播种以 `apps/api` 为 cwd 跑(`pnpm --filter @app/api seed`),所以默认往上两级找;
 * 容器化或换布局时用 `JCAI_ACTIVITIES_DIR` 顶掉 —— 路径是部署事实,不该写死在代码里。
 */
function activitiesRoot(): string {
  const override = process.env['JCAI_ACTIVITIES_DIR'];
  return override === undefined || override.trim() === ''
    ? resolve(process.cwd(), '..', '..', 'activities')
    : resolve(override);
}

export async function installRealActivities(container: Container): Promise<void> {
  const log = (line: string) => process.stdout.write(line + '\n');

  /*
   * **主数据先于活动物化**(2026-07-31)。
   *
   * 客户 / 项目 / 供应商 / 市场四域不挂在任何活动名下:主数据不是谁的产出,
   * 它先于活动存在、活动退役了它还在,活动只是读它做判断、提议更新它。
   * 挂在活动清单下的后果刚踩过 —— 那个活动一退役,它声明的表就成了没人认领的空壳。
   *
   * 放在装活动**之前**:活动声明里若也提到同一张表(它要写的那几列),
   * 声明合并是「最大化合并、只增不破坏」,平台给的全量结构先落地,活动只补自己那部分。
   */
  const applied = await container.ledger.applyDeclarations(MASTER_OBJECTS);
  const conflicts = applied.flatMap((r) => r.conflicts);
  log(
    `   主数据四域已物化:${MASTER_OBJECTS.length} 张表` +
      // 冲突要如实报:静默吞掉的话,表结构和声明对不上而没人知道
      (conflicts.length === 0 ? '' : ` —— 合并冲突 ${conflicts.length} 处:${conflicts.map((c) => c.field).join('、')}`),
  );
  const root = activitiesRoot();

  for (const dir of REAL_PACKAGES) {
    const dist = join(root, dir, 'dist');
    let manifestJson: string;
    let entryJs: string;
    try {
      [manifestJson, entryJs] = await Promise.all([
        readFile(join(dist, 'manifest.json'), 'utf8'),
        readFile(join(dist, 'index.js'), 'utf8'),
      ]);
    } catch {
      log(`   活动包 ${dir} 没有构建产物(${dist})—— 先跑 pnpm activities:build;本次跳过`);
      continue;
    }

    const parsed = activityManifestSchema.safeParse(JSON.parse(manifestJson));
    if (!parsed.success) {
      // 清单不合协议就别装:装进去的残清单会在起单那一刻才炸,那时更难查
      log(`   活动包 ${dir} 的清单不合协议:${parsed.error.issues.map((i) => `${i.path.join('.')} ${i.message}`).join('; ')}`);
      continue;
    }

    /*
     * 安装恒新增、版本并存:同版本重装是 no-op(静默丢失 —— 踩过)。
     * 所以改了内容必须在包里升 `identity.packageVersion`,不然播种看着成功、内容还是旧的。
     */
    try {
      const verdict = await container.registry.install(parsed.data, entryJs);
      const version = parsed.data.identity.packageVersion;
      /*
       * **装的时候把声明的工具一并授权**(2026-07-31 补)。
       *
       * 从前授权只在 `seed-mvp` 里发 —— 那是治理台的整套配置播种。
       * 于是经安装通道装进来的真活动包一件工具也调不动:A4 的说明书让它去取历史价,
       * 清单里也白纸黑字声明了 `crm.history-price-read`,运行时却拒回
       * 「工具不在本活动白名单」,连拒五拍熔断(实测 A4 死于此)。
       * 「系统外开发、安装即用」里的「即用」,包含它声明过的那些工具能调得动;
       * 声明了却不授权,等于装了一个结构上办不成事的活动。
       *
       * 授权面**就是清单声明**,不多给一件:越权在结构上仍然不可能。
       */
      const declared = parsed.data.declarations.tools.map((t) => t.name);
      await container.toolbox.setAllowlist(parsed.data.identity.activityId, declared);
      log(
        `   活动包已装:${parsed.data.identity.name}(${parsed.data.identity.activityId}@${version})` +
          (declared.length === 0 ? '' : ` · 已授权工具 ${declared.length} 件`) +
          (verdict.staticFindings.length === 0
            ? ''
            : ` —— 静态审提示:${verdict.staticFindings.map((f) => `[${f.severity}] ${f.message}`).join('; ')}`),
      );
    } catch (error) {
      log(`   活动包 ${dir} 未过安装两审:${error instanceof Error ? error.message : String(error)}`);
    }
  }

  /*
   * **样例客户 —— 装完全部活动包之后再播种**(2026-08-20 改序,踩过坑):
   * `MASTER_SAMPLE_ROWS` 里带着 E04 追加的列(`cust_type`/`decision_chain`…)——
   * 这些列要等 `crm-relationship-coverage` 装进 `REAL_PACKAGES` 循环、
   * 它的台账声明经 `applyDeclarations` 做过 `add-column` 之后才真的存在于物理表。
   * 原来放在装活动**之前**播种,种到这些新列时 Postgres 直接报
   * `column "cust_type" of relation "customer__profile" does not exist`——
   * 主数据物化(平台基线列)在活动之前没错,但样例数据要用到**活动追加的列**时,
   * 必须排在对应活动装完之后。按主键写,重复播种是覆盖不是堆叠;写正式版
   * (不是草稿层),因为 A1 第一步查的就是正式版 —— 草稿只有本任务自己看得见。
   */
  for (const row of MASTER_SAMPLE_ROWS) {
    await container.ledger.systemWrite({
      address: { domain: row.address.domain, object: row.address.object },
      key: { ...row.key },
      values: { ...row.values },
      cause: { kind: 'governance', ref: 'seed:master-sample' },
    });
  }
  log(`   样例客户已就位:${MASTER_SAMPLE_ROWS[1]?.values.email ?? ''}(样例 2 用它试老客户那条路)`);
}