Known unresolved product and operational limitations; architecture migration gaps are tracked in current status.
Each entry states what is wrong, how it shows up, and where the fix goes. Other pages link here rather than restating them.
Fixed issues are deleted, not archived. Renumber the rest and update the anchors —
npm run check:docs catches any that are missed. Git history is the record of what was
already fixed.
Known failures on compatibility-retry paths still have no general product retry budget or alerting policy. The app compiler now expresses recovery/backoff as closed syntax; this is not an uncaught native handler loop. Uncertain transport outcomes do not take that path: they hold for reconciliation. Do not “fix” repeated known failures by blindly retrying uncertain writes.
Stronger per-operation idempotency, reconciliation, retry deadlines and operator visibility are tracked in the Platform roadmap.
The stored machine distinguishes failure from successful completion. The public compatibility
DTO still exposes status: "running" | "completed" plus error. Clients that count completed
status without inspecting error can misclassify failed outcomes. Records already derive a
separate outcome. Changing the public status vocabulary remains an explicit API/UX decision,
not a mechanical internal-state change.
enabledExpression is defined but never evaluatedThe app authoring model/editor round-trips this field, but compilation does not turn it into an
execution gate. It remains unsupported compatibility metadata. Source runInputs and
startExpression likewise must not be mistaken for enforced start authorization.
Implementing these product semantics or removing the inactive controls requires an explicit choice and tests; merely preserving source data does not deliver the behavior.
The earlier no-test-suite description is obsolete. The repository now has Node tests,
per-project coverage, compiled HTTP checks, browser/worker journeys, packed-consumer
checks and dependency-boundary enforcement. Run npm run verify; see the
verification guide and current status.
This does not make coverage exhaustive. Live identity/provider behavior, Mongo and broader concurrency paths remain unverified; parts of UI/domain/adapter Node coverage are thin. No general code-linting suite has been added. Hosted CI must run on the submitted commit; a local passing gate is not proof of branch protection or hosted enforcement.
applications/main/src/lib/openapi.ts powers /docs/api but is hand-maintained. Canonical registrations and
process projections changed the wire model; compare the spec with the actual route contracts
and built HTTP tests rather than assuming a documented schema is authoritative. A generated
contract or explicit drift gate remains preferable to a second manually duplicated description.
Packed consumers, synthetic browser journeys and local concurrency tests do not validate actual Auth0 tenants, external providers, hosting configuration or production record sizes. Follow deployment bindings and migration and obtain explicit rollout approval. Unknown historical definitions and uncertain automatic states cannot simply be started under the new worker.
applications/main/src/app/page.tsx:115
awaitingSignoff: 0,
Never computed. The dashboard card most likely to be acted on always reads 0,
regardless of how many steps are waiting on you.
Fix: compute it the way ConduitPipelineHome already does — compare the current
step's permissions[] against the viewer's, across running processes. That logic exists
in applications/allocation-risk/src/components/allocation-risk/conduit-pipeline-home.tsx (isYourTurn) and could
move somewhere shared. Or remove the card until it works.
Two adjacent screens read the same document and reach different conclusions.
/processes derives a failure state, because status cannot express one:
if (r?.outcome === "rejected" || r?.status === "rejected") return "rejected"; if (typeof p.error === "string" && p.error.length > 0) return "rejected";
/ does not — it counts status === "completed", so failed runs inflate "Completed
This Week" and their durations are folded into "Avg. Completion Time".
This is a symptom of issue 2, not an
independent bug. It is worth listing separately because it shows the cost: the same
"did this fail?" logic is now re-derived in three places — /processes,
ConduitPipelineHome, and RecordOutcome in records — each slightly
different. Fixing ProcessStatus deletes all three.
applications/main/src/app/processes/page.tsx, progressParts():
den = template.steps.length num = index of the current step in template.steps
Steps are a linked list — array order carries no meaning. For a template whose steps happen to be declared in execution order this looks right; for one that branches, loops, or is declared out of order it is arbitrary. A rework loop can sit at "90%" indefinitely, and progress can move backwards.
It reads as a completion percentage and is not one.
Fix: either walk nextStepKey from firstStepKey to get a real position (still
undefined for branches), count reached steps against reachable steps, or drop the
numeric claim and show the phase instead.
A fresh local dependency audit reports 57 advisory entries, including 3 critical entries involving
Next 14.2.35, concurrently 9.2.1 and shell-quote 1.8.3. Their versions match the pre-rewrite
150b70d lockfile. This establishes pre-existing package exposure, not application exploitability.
No automatic audit-fix or major framework upgrade was applied. Scope remediation separately, review the affected paths and rerun regression/security checks before rollout. Do not classify this as deferred language-migration work or treat passing functional tests as vulnerability clearance.