hub/tasks/architecture/storage/add-cross-project-dep-guard.md at 2b63cda1c76446ac4662aa2be9ddad6d90cc4bfe

alkdev/hub

Files

glm-5.1 2b63cda1c7 Setup repo: migrate architecture specs, code stubs, and tasks from alkhub_ts

Copy architecture docs, ADRs, storage domain specs, research, reviews,
and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for
standalone @alkdev/hub repo structure (src/ not packages/hub/).

Sanitize all sensitive information:
- Replace private IPs (10.0.0.1) with localhost defaults
- Remove internal server hostnames (dev1, ns528096)
- Replace /workspace/ private paths with npm package references
- Remove hardcoded credentials from examples
- Rewrite infrastructure.md without private network details

Add Deno project scaffolding: deno.json (pinned deps), .gitignore,
AGENTS.md, entry point. Migrate existing code stubs (crypto, config
types, logger) with updated import paths.

2026-05-25 10:56:32 +00:00

1.6 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

add-cross-project-dep-guard

Add DB-level guard for cross-project task dependencies

completed

narrow

medium

component

implementation

Description

"Tasks can only depend on tasks within the same project" is declared in tasks.md:217 but only "enforced at the application level." task_dependencies has FK columns with no projectId or check constraint. Application-level enforcement is vulnerable to race conditions, direct SQL access, or bugs.

Choose one:

(A) Add a DB trigger that checks dependsOnTaskId and taskId belong to the same project
(B) Add a denormalized projectId column to task_dependencies with a composite FK
(C) Document the risk explicitly and specify that the sync operation validates project scope within a transaction (SELECT FOR SHARE)

Acceptance Criteria

The chosen enforcement mechanism is documented in tasks.md
If option A: trigger definition is specified; tasks.md notes the trigger name and behavior
If option B: projectId column is added to task_dependencies schema; composite FK documented; table-reference.md updated
If option C: the risk is documented and the sync validation pattern is specified (SELECT FOR SHARE + INSERT in same transaction)
The cross-project dependency invariant is restated in tasks.md with the enforcement mechanism

References

docs/reviews/storage-architecture-review-2026-04-21.md#C09
docs/architecture/storage/tasks.md:217
docs/architecture/storage/tasks.md:357

Notes

To be filled by implementation agent

Summary

To be filled on completion

1.6 KiB Raw Blame History