page:blueprints:architecture practices:project tracker:django

Architecture practices: project tracker using Django

Summary

A project tracker blueprint for architecture practices built with Django on Ample. Domain schema: client_entities (name, entity_type, site_address): clients and project sites; projects (client_entity_id, project_name, stage, period_start, period_end): engagement periods by RIBA/AIA-style stage; drawing_sets (project_id, set_name, revision, object_key, issued_at): versioned drawing issues; approvals (project_id, drawing_set_id, approver_role, decided_at, decision): client sign-offs per issue; state_transitions (record_type, from_state, to_state): the allowed state machine. Public information: portfolio and services, team and accreditations, studio locations. Kept out of scope until handling is reviewed: unreleased drawings and site surveys, planning submissions before filing, client contact details. Drawings and surveys are client-confidential until issued; the portal models per-project authorization only. Technical basis verified on Django: a workspace-scoped table, an explicit state machine (draft to review to published) that rejects invalid transitions, and a cross-workspace read that returns nothing (transitions=true isolation=true).

Representative Queries

Workflow Steps

  1. Model the architecture practices domain: Create the tables client_entities, projects, drawing_sets, approvals, state_transitions. Clients and project sites lives in client_entities; keep the sensitive classes (unreleased drawings and site surveys, planning submissions before filing, client contact details) out of this schema.
  2. Workflow step 1: Model engagements and workstreams with explicit status transitions
  3. Workflow step 2: Scope every query by client entity
  4. Workflow step 3: Attach deliverables as private objects linked to workstreams
  5. Workflow step 4: Deploy and verify transitions and cross-client isolation
  6. Deploy: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.
    ample deploy . --name  --public --start "python3 run.py" --env S3_ENDPOINT=... --env S3_REGION=... --env S3_BUCKET=... --env S3_ACCESS_KEY_ID=... --env S3_SECRET_ACCESS_KEY=...
  7. Verify: Run the pattern self-test(s) from the example (/p/relational-records) and your own acceptance checks for the architecture practices workflow.
    ample logs  --kind build

Limitations

Success Checks

  1. App responds on its public URL
    • Kind: http_get
    • Path: /
    • Expect: ample canary django patterns
  2. Relational-records self-test from the example
    • Kind: http_get
    • Path: /p/relational-records
    • Expect: see the pattern fixture checks

Cost Estimate

Components

Note: Always-on monthly price of the tested sizes; apps and databases auto-pause when idle. Buckets are allocation-priced per quota and not included.

Examples

Evidence Summary

Next Actions