Merge worktree-issue-21: Normalize active DataOps branding (#21)

Author: alexeygrigorev

.github/workflows/assistant-ci.yml

@@ -17,8 +17,8 @@ permissions:
   contents: read
 
 jobs:
-  podcast-assistant:
-    name: Podcast Assistant tests
+  dataops-podcast-module:
+    name: DataOps podcast assistant tests
     runs-on: ubuntu-latest
 
     steps:
@@ -31,7 +31,7 @@ jobs:
       - name: Install Python
         run: uv python install 3.13
 
-      - name: Run Podcast Assistant unit tests
+      - name: Run DataOps podcast assistant unit tests
         run: uv run --project assistants/podcast pytest
 
       - name: Verify real-engine tests are opt-in

README.md

@@ -8,17 +8,19 @@ Version 1 focuses on operations docs and tasks:
 - task workflows, bundles, recurring work, required links, and execution state
 - AWS Lambda deployment with GitHub Actions OIDC
 
-The first deployed app uses the DTC Operations docs portal as the base Lambda
-application. DataTasks is imported under `work-engine/` for the task execution
-engine, and the podcast assistant is imported under `assistants/podcast/` for
-the podcast operations workflow.
+The deployed V1 app is the DataTalks.Club operations portal for
+`ops.dtcdev.click`, served from the `DataTalksClub/dataops` repository and the
+`dataops-v1` stack. The work engine lives under `work-engine/` as an internal
+DataOps task/workflow module, and the podcast assistant lives under
+`assistants/podcast/` as a DataOps assistant module for the podcast operations
+workflow.
 
 ## Layout
 
 - `content/` — operational documentation (SOPs, templates, references,
   playbooks, prompts) and its image assets.
-- `work-engine/` — imported DataTasks task execution system.
-- `assistants/podcast/` — imported podcast workflow assistant, process docs,
+- `work-engine/` — DataOps task/workflow execution module.
+- `assistants/podcast/` — DataOps podcast workflow assistant module, process docs,
   guest-intake template, knowledge-base builder, and tests.
 - `docs/` — repo-meta docs (this README, `STRUCTURE.md`, `sop-format*.md`,
   archived materials).

assistants/podcast/README.md

@@ -1,10 +1,12 @@
-# Podcast Assistant
+# DataOps Podcast Assistant Module
 
-Telegram assistant for collecting podcast prep material and generating podcast guest documents.
+DataOps assistant module for collecting podcast prep material and generating
+podcast guest documents.
 
-This directory is the canonical in-repo Podcast Assistant location for DataOps:
-`assistants/podcast/`. The old root-level `podcast-assistant/` import has been
-folded into this module.
+This directory is the canonical in-repo podcast assistant location for DataOps:
+`assistants/podcast/`. The old root-level `podcast-assistant/` import name is
+retained here only as migration history; active development uses this module
+path.
 
 This is copied from the Telegram Writing Assistant shape, but the agent execution boundary uses
 Heru instead of calling Claude directly. Set `HERU_ENGINE=codex` or `HERU_ENGINE=claude` to choose

assistants/podcast/dry_run.py

@@ -1,4 +1,4 @@
-"""Deterministic Podcast Assistant dry-run boundary for DataOps job payloads."""
+"""Deterministic DataOps podcast assistant dry-run boundary for job payloads."""
 
 from __future__ import annotations
 

assistants/podcast/pyproject.toml

@@ -1,7 +1,7 @@
 [project]
-name = "podcast-assistant"
+name = "dataops-podcast-module"
 version = "0.1.0"
-description = "Telegram assistant for collecting podcast prep notes and generating guest question documents."
+description = "DataOps podcast assistant module for collecting prep notes and generating guest question documents."
 readme = "README.md"
 requires-python = ">=3.13"
 dependencies = [

assistants/podcast/uv.lock

@@ -53,7 +53,7 @@ Use one of these `doc_type` values in frontmatter:
 - `sop` - step-by-step instructions for doing operational work.
 - `checklist` - ordered checklist that links to SOPs or summarizes a multi-step workflow.
 - `template` - reusable text, email, contract, announcement, or prompt template.
-- `task-template` - Git-backed DataTasks workflow template.
+- `task-template` - Git-backed DataOps workflow template.
 - `reference` - overview, index, FAQ, guide, spreadsheet export, or troubleshooting reference.
 - `playbook` - campaign or strategy plan, usually with multiple activities and references.
 - `prompt` - maintained AI prompt.

docs/STRUCTURE.md

@@ -152,19 +152,19 @@ flowchart LR
 
 Current workflows:
 
-- `.github/workflows/validate-docs-content.yml`
+- `.github/workflows/validate-dataops-content.yml`
   - Runs for `content/**` changes.
   - Builds the search index from `content/`.
   - Smoke-tests search against the generated index.
   - On pushes with changed content files, assumes the AWS OIDC deploy role and
     directly invokes the deployed Lambda refresh endpoint.
   - Does not deploy Lambda code.
-- `.github/workflows/deploy-full-docs-lambda.yml`
+- `.github/workflows/deploy-dataops-v1.yml`
   - Runs for frontend, Lambda, infra, package, deploy script, and docs-app test
     changes.
   - Runs tests and deploys the full app Lambda stack if checks pass.
-- `.github/workflows/deploy-api-lambda.yml`
-  - Legacy or separate API Lambda deploy path.
+- `lambda-functions/template.api.yaml`
+  - Legacy or separate API Lambda deploy path retained for compatibility.
 
 ## Credentials and CloudFormation
 
@@ -173,8 +173,8 @@ long-lived AWS keys in GitHub.
 
 ```mermaid
 flowchart TB
-  CFN[template.github-actions.yaml] --> OIDCProvider[GitHub OIDC provider]
-  CFN --> Role[dtc-operations-github-actions-deploy role]
+  CFN[template.github-actions-dataops.yaml] --> OIDCProvider[GitHub OIDC provider]
+  CFN --> Role[dataops-v1 GitHub Actions deploy role]
   GitHubActions[GitHub Actions] -->|OIDC token| Role
   Role -->|limited deploy permissions| SAM[SAM deploy]
 ```
@@ -190,8 +190,8 @@ Runtime secrets are also managed through CloudFormation:
 
 The main runtime secrets are:
 
-- `dtc-operations/full-app/github-token`
-- `dtc-operations/full-app/basic-auth-password`
+- `dataops-v1/full-app/github-token`
+- `dataops-v1/full-app/basic-auth-password`
 
 ## Why Not EFS Right Now
 

docs/architecture.md

@@ -36,9 +36,10 @@ Current state:
   `ops.dtcdev.click`.
 - `content/` is the transitional Git home for imported SOPs, references,
   images, prompts, indexes, and task templates.
-- `content/tasks/templates/` contains DataTasks workflow templates that encode
+- `content/tasks/templates/` contains DataOps workflow templates that encode
   repeatable operational process.
-- `assistants/podcast/` is the canonical in-repo Podcast Assistant module.
+- `assistants/podcast/` is the canonical in-repo DataOps podcast assistant
+  module.
 - Runtime workflow state is stored in DynamoDB execution tables managed by the
   deployed stack.
 - Private or bulky files must remain outside public process documentation.
@@ -162,9 +163,9 @@ Rules:
 - Curated examples may move only after data review confirms they are safe,
   useful, and intentionally public.
 
-## DataTasks Template Decision
+## DataOps Workflow Template Decision
 
-DataTasks templates are canonical process knowledge, not runtime state.
+DataOps workflow templates are canonical process knowledge, not runtime state.
 
 Canonical Git location after migration:
 
@@ -209,7 +210,7 @@ Runtime behavior:
 ## Assistant Boundary
 
 `assistants/podcast/` remains the canonical product-code location for the
-Podcast Assistant in `dataops`.
+DataOps podcast assistant module in `dataops`.
 
 Keep in `dataops`:
 
@@ -417,9 +418,9 @@ Create these after ADR acceptance:
    validation, authoring, and revert behavior.
 9. Wire knowledge-repo CI to refresh the deployed portal cache/search index
    without app redeploy.
-10. Classify and migrate reusable Podcast Assistant process knowledge,
+10. Classify and migrate reusable DataOps podcast assistant process knowledge,
     templates, prompts, and safe knowledge-base summaries.
-11. Move Podcast Assistant generated/private outputs to private artifact
+11. Move DataOps podcast assistant generated/private outputs to private artifact
     storage and attach artifact metadata to workflow records.
 12. Add admin/status visibility for loaded knowledge repo branch, commit SHA,
     index build time, and template sync version.
@@ -430,7 +431,7 @@ Positive:
 
 - App code, process knowledge, runtime state, and private artifacts have clear
   ownership.
-- DataTasks templates remain reviewable and recoverable in Git.
+- DataOps workflow templates remain reviewable and recoverable in Git.
 - Docs and template changes can eventually ship without app redeploys.
 - The portal can keep a unified operator experience while the internals stay
   separated.

docs/decisions/dataops-knowledge-repository.md

@@ -34,8 +34,8 @@ process docs in context without switching between disconnected tools.
 This is not a generic documentation site system and not a generic admin
 dashboard system. Docs remain important, but V1 is workflow-first: daily work,
 proof, reminders, follow-ups, workflow state, and assistant artifacts are the
-primary product surface. The calmer portal direction is the baseline. Legacy
-DataTasks work-engine patterns are migration targets.
+primary product surface. The calmer portal direction is the baseline. Imported
+work-engine UI patterns are migration targets.
 
 Primary inputs:
 
@@ -73,7 +73,7 @@ Follow-up implementation issue:
    Done states require acceptance criteria and proof when the task requires a
    link, file, artifact, or review record.
 6. Assistant output is operational output.
-   Podcast Assistant and future assistant UI must reuse DataOps components for
+   DataOps podcast assistant and future assistant UI must reuse DataOps components for
    jobs, artifacts, logs, approvals, retries, and review actions. They must not
    introduce a second assistant-specific visual language.
 7. Incremental implementation.
@@ -238,7 +238,7 @@ Layer rules:
 | Canonical token | Current portal source | Current work-engine source | Migration note |
 | --- | --- | --- | --- |
 | `--do-color-bg` | `--bg` | `--bg` in polish layer, `#f5f5f5` legacy body | Alias both to canonical. |
-| `--do-color-shell` | `--sidebar` | `nav` legacy `#2c3e50` and mobile nav surface | Replace DataTasks nav with DataOps shell later. |
+| `--do-color-shell` | `--sidebar` | `nav` legacy `#2c3e50` and mobile nav surface | Align the work-engine nav with the DataOps shell after token migration. |
 | `--do-color-surface` | `--surface` | `--surface`, many `#fff` rules | Alias and remove hard-coded white over time. |
 | `--do-color-border` | `--line` | `--border`, `#ddd`, `#e0e0e0`, `#eee` | Normalize borders before component migration. |
 | `--do-color-accent` | `--accent` | `--primary`, `#3498db` | Portal accent is canonical; work-engine blue becomes alias only. |
@@ -551,7 +551,7 @@ Canonical primitives: `do-assistant-job-row`, `do-assistant-output-panel`,
 
 Usage rules:
 
-- Podcast Assistant and future assistant UI must reuse DataOps shell, panels,
+- DataOps podcast assistant and future assistant UI must reuse DataOps shell, panels,
   cards, buttons, status badges, file rows, empty states, and proof/artifact
   controls.
 - Assistant jobs are workflow-linked operational items. They should show job
@@ -613,7 +613,7 @@ Portal drift to address:
 
 Work-engine drift to address:
 
-- Brand still says `DataTasks`; V1 shared shell should say `DataOps`.
+- Work-engine brand now says `DataOps`; V1 still needs shared shell and token convergence.
 - Sticky top nav is a legacy admin pattern beside the portal sidebar shell.
 - Blue primary buttons and blue hover borders conflict with DataOps teal.
 - Card-heavy dashboards, large mobile form cards, and empty states reduce
@@ -639,10 +639,10 @@ Work-engine drift to address:
    Align task rows, workflow cards, progress, required proof, and follow-up
    controls across Operations Home and work-engine.
 6. Work-engine shell cleanup.
-   Replace DataTasks top nav and generated inline class fragments after tokens
-   and core primitives are stable.
+   Replace the imported work-engine top nav and generated inline class
+   fragments after tokens and core primitives are stable.
 7. Assistant UI reuse.
-   Build Podcast Assistant and future assistant surfaces only on shared panels,
+   Build DataOps podcast assistant and future assistant surfaces only on shared panels,
    artifacts, status badges, buttons, and empty states.
 
 ## Responsive Rules
@@ -731,7 +731,7 @@ Work-engine drift to address:
 
 - Work-engine generated inline styles in `app.js` for forms, task definitions,
   required links, and recurring controls.
-- Work-engine DataTasks top nav and route link structure.
+- Imported work-engine top nav and route link structure.
 - Clickable cards that need consistent role, tab index, and keyboard handling.
 - Mobile task route ordering so active tasks are not pushed below long filters
   and create forms.
@@ -791,7 +791,7 @@ Phase 4: Unified task and workflow execution.
 
 Phase 5: Assistant surfaces.
 
-- Build Podcast Assistant and future assistant UI with shared shell, panel,
+- Build DataOps podcast assistant and future assistant UI with shared shell, panel,
   artifact row, status badge, empty state, and review action primitives.
 - Link assistant artifacts to workflows and tasks using the same proof/evidence
   controls.