Skip to content

Decision 0009 — Modernization Plugin Reuse And Greenfield Boundary

  • Status: APPROVED
  • Date: 2026-08-18
  • Scope: new-system/**
  • Decision owner: user-approved Logistics Workspace program direction

Context

The Legacy repository contains both:

  • independently reusable modernization plugins such as KJTable and KJModal;
  • mixed page, global, API and business modules that remain tightly coupled and have caused regressions when changed in place.

The Logistics Workspace was separated to prevent successor development from repeatedly modifying the operating Legacy runtime.

Decision

Frontend, application logic, APIs and backend authority are rebuilt under new-system/**.

An independently reusable modernization plugin may use one of two paths:

COPY_AND_OWN
= copy exact source into a Logistics Workspace-owned boundary, record provenance,
  trim dependencies, modularize and wrap behind a typed contract

NATIVE_REACT
= replace the capability with a native React implementation

The active Task chooses the path for the exact component. Repeated broad design analysis is not required.

COPY_AND_OWN Requirements

  • record source repository revision and exact copied paths;
  • copy only the plugin and bounded required dependencies;
  • do not import or serve the root Legacy asset tree at runtime;
  • expose a typed adapter used by canonical page code;
  • confine temporary globals to the copied plugin boundary;
  • move query, command, validation, tenant and recovery logic into Logistics Workspace owners;
  • retain/port focused plugin regression tests;
  • permit later native replacement without changing business contracts.

Prohibited Reuse

  • copying complete Legacy pages or mixed business modules;
  • calling root Legacy PHP/API endpoints as the canonical implementation;
  • modifying root Legacy code so Logistics Workspace pages work;
  • plugin-owned SQL, business policy, authorization or transaction orchestration;
  • direct canonical-page dependence on window.KJ* or root asset URLs;
  • treating visual restyling alone as Logistics Workspace completion.

Compatibility

Compatibility means preserving accepted behavior, data, entry paths and rollback—not retaining the same internal code.

Legacy remains independently usable until separate route/writer cutover and caller-zero evidence.

Consequences

  • some UI may retain proven modernized interaction behavior while being visually and structurally integrated into the Logistics Workspace;
  • mixed Legacy modules are rebuilt rather than patched;
  • plugin provenance and adapter boundaries become testable architecture constraints;
  • native React remains available when copied-plugin coupling is not bounded.

---

Source: new-system/docs/decisions/0009-modernization-plugin-reuse-and-greenfield-boundary.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.