sddflow 2.7.92__tar.gz → 2.7.99__tar.gz

sddflow-2.7.92/README.md → sddflow-2.7.99/PKG-INFO

@@ -1,3 +1,38 @@
+Metadata-Version: 2.4
+Name: sddflow
+Version: 2.7.99
+Summary: Spec-Driven Development CLI for AI coding agents — SDLC workflows with Jira/Confluence sync, multi-host PR automation, and live progress dashboards
+Project-URL: Homepage, https://github.com/sunil1983us/universalguide
+Project-URL: Repository, https://github.com/sunil1983us/universalguide
+Project-URL: Bug Tracker, https://github.com/sunil1983us/universalguide/issues
+Project-URL: Changelog, https://github.com/sunil1983us/universalguide/blob/main/CHANGELOG.md
+Author-email: Sunil Kumar <sunil1983.us@gmail.com>
+License: MIT
+Keywords: ai,ai-agent,atlassian,claude,claude-code,code-review,confluence,jira,llm,pull-request,requirements,sdd,sdlc,spec-driven-development,specification
+Classifier: Development Status :: 5 - Production/Stable
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.9
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Topic :: Software Development
+Classifier: Topic :: Software Development :: Documentation
+Classifier: Topic :: Utilities
+Requires-Python: >=3.9
+Requires-Dist: click>=8.0
+Requires-Dist: keyring>=24.0
+Requires-Dist: pyyaml>=6.0
+Requires-Dist: questionary>=2.0
+Requires-Dist: requests>=2.28
+Requires-Dist: rich>=13.0
+Provides-Extra: diagrams
+Requires-Dist: mmdr>=0.3.0; extra == 'diagrams'
+Description-Content-Type: text/markdown
+
 # sddflow (Python) — SDD Framework CLI
 
 Python CLI for the SDD (Spec-Driven Development) Framework.  
@@ -96,23 +131,40 @@ sdd config init
 ```
 
 Walks through:
-1. Profile name (e.g. `work-cloud`, `on-prem`)
-2. Atlassian base URL
-3. Auth mode — see [Auth Modes](#auth-modes) below
-4. **Credential storage** — system keychain (recommended) or environment
-   variable, see [Credential Storage](#credential-storage) below
-5. Optionally scaffolds `.specify/integrations.yml` — project key,
-   Confluence space key, and parent page ID are filled into your pack's own
-   shipped `.specify/integrations.yml.example`, so every section it
-   documents (`project_keys`, `parent_field_by_level`,
-   `custom_fields_by_level`, `diagrams`, `document_reviews`,
-   `pr_automation`, `code_review`, the full `page_map`) is present from the
-   start, not just the handful the wizard asks about — most stay commented
-   out until you need them. `document_reviews` ships with placeholder Jira
-   accountIds from the example; replace them with real reviewers (or delete
-   entries you don't want routed through Jira) before `sdd review submit`.
-   Falls back to a minimal built-in template only if no `.example` file
-   exists in the project.
+1. **Do Jira and Confluence share the same site and credentials?**
+   - **Yes** (the common Cloud case, one Atlassian site serving both) —
+     collects one profile: name (e.g. `work-cloud`, `on-prem`), Atlassian
+     base URL, auth mode (see [Auth Modes](#auth-modes)), and credential
+     storage (see [Credential Storage](#credential-storage)).
+   - **No** (typical for Server/Data Center, where Jira and Confluence run
+     as separate servers with separate credentials) — runs that same
+     round *twice*, once per service, producing two independent profiles
+     in `~/.sdd/config.yml`. A profile is the entire auth set — base URL +
+     auth mode + credential — not just a URL, so the two are never assumed
+     to overlap even if a base URL happens to coincide.
+2. Optionally scaffolds `.specify/integrations.yml` — project key,
+   Confluence space key, and parent page (ID **or** a pasted page URL —
+   see below) are filled into your pack's own shipped
+   `.specify/integrations.yml.example`, so every section it documents
+   (`project_keys`, `parent_field_by_level`, `custom_fields_by_level`,
+   `diagrams`, `document_reviews`, `pr_automation`, `code_review`, the full
+   `page_map`) is present from the start, not just the handful the wizard
+   asks about — most stay commented out until you need them.
+   `document_reviews` ships with placeholder Jira accountIds from the
+   example; replace them with real reviewers (or delete entries you don't
+   want routed through Jira) before `sdd review submit`. Falls back to a
+   minimal built-in template only if no `.example` file exists in the
+   project. In "No" mode, the top-level `profile:` is wired to Jira's
+   profile and `confluence.profile:` is filled with Confluence's — no
+   manual edit needed.
+
+**Confluence parent page — ID or URL, either works.** Paste whatever
+you have open: a bare numeric ID (`123456`), a Cloud URL
+(`.../spaces/ENG/pages/123456/Page+Title`), or a Server/Data Center URL
+(`...?pageId=123456`) — the numeric ID is extracted automatically. A
+Confluence "tiny link" (`.../x/AbCdEf`) isn't a page ID and can't be
+resolved without an API call; the wizard warns and uses it as-is if you
+paste one — open the page and copy the full URL instead.
 
 ---
 
@@ -141,12 +193,29 @@ sdd config test
 sdd config test --profile on-prem
 ```
 
-Output:
+Without `--profile`, Jira and Confluence are each resolved independently
+through `integrations.yml`'s `jira.profile`/`confluence.profile` (falling
+back to the top-level `profile:` when unset) — so a split-profile setup
+tests each service against its own `base_url`/credentials, not one
+profile's server used for both. An explicit `--profile` always tests that
+one profile against both services, overriding the split — useful for
+sanity-checking a profile before wiring it into `integrations.yml`.
+
+Output (single profile, or no split configured):
 ```
   ✓  Jira       — connected as Jane Smith
   ✓  Confluence — connected as Jane Smith
 ```
 
+Output (Jira and Confluence on separate servers):
+```
+  Jira profile:       jira-dc
+  Confluence profile: confluence-dc
+
+  ✓  Jira       — connected as Jane Smith
+  ✓  Confluence — connected as Jane Smith
+```
+
 ---
 
 ### `sdd config fields`
@@ -320,8 +389,9 @@ What it does:
 3. Ensures a Feature/Epic issue exists for the project — normally already
    created by `/specify` before any spec document exists (see `sdd jira push
    --level epic` below); self-bootstrapped here too as a fallback, refreshed
-   with the BRD's Business Objectives if they weren't available yet — and
-   creates (or updates) a Jira **Story** with the label
+   with the BRD's content (Problem Statement, Business Hypothesis,
+   Description, Out of Scope) if it wasn't available yet — and creates (or
+   updates) a Jira **Story** with the label
    `sdd-doc:{feature}:{doc}`, parented under that Epic and assigned to the
    configured reviewer
 
@@ -936,6 +1006,12 @@ profiles:
     pat_env: JIRA_PAT
 ```
 
+A profile is the *entire* auth set — base URL, auth mode, and credential —
+not just a URL. `sdd config init` answering "No" to "same site and
+credentials?" creates two of these (e.g. `jira-dc` + `confluence-dc`) in
+one run, for orgs where Jira and Confluence are separate Server/Data
+Center instances with separate tokens.
+
 ---
 
 ### `.specify/integrations.yml` — project-level, safe to commit
@@ -944,10 +1020,13 @@ Wires SDD fields to your Jira project and Confluence space.
 Copy from `.specify/integrations.yml.example` and fill in your values.
 
 ```yaml
-profile: work-cloud     # references a profile in ~/.sdd/config.yml
+profile: work-cloud     # references a profile in ~/.sdd/config.yml -- Jira's
+                         # profile if jira.profile is unset (see below)
 
 jira:
   project_key: MYPROJ
+  # profile: jira-dc     # optional: override the top-level profile for
+                          # Jira calls only (separate Data Center server)
   # Optional: per-level overrides when Features live in one Jira project
   # and Stories/Tasks live in another. Any level not listed falls back
   # to project_key. Valid levels: feature, story, task, review, chg, cr.
@@ -985,14 +1064,24 @@ jira:
   #     story_points: customfield_99001
 
 confluence:
+  # profile: confluence-dc   # optional: override the top-level profile for
+                              # Confluence calls only (separate Data Center server)
   space_key: ENG
-  parent_page_id: "123456"
+  parent_page_id: "123456"   # bare ID, a Cloud URL, or a Server/DC "?pageId="
+                              # URL all work -- the ID is extracted automatically
   page_map:
     brd:     "{feature} — Business Requirements"
     hld:     "{feature} — High-Level Design"
     runbook: "Runbook"   # living doc -- no {feature}, nests under the Project page
 ```
 
+`jira.profile` / `confluence.profile` let the two services point at
+different `~/.sdd/config.yml` profiles — each falls back to the top-level
+`profile:` when unset, so existing single-profile projects need no
+changes. `sdd config init` wires these automatically when you answer "No"
+to the same-site question; hand-editing is only needed if you're adding
+the split to a project that was already scaffolded single-profile.
+
 Full reference: see `.specify/integrations.yml.example`.
 
 **`project_keys` cross-project caveat:** Jira's parent/Epic-Link field

sddflow-2.7.92/PKG-INFO → sddflow-2.7.99/README.md

@@ -1,38 +1,3 @@
-Metadata-Version: 2.4
-Name: sddflow
-Version: 2.7.92
-Summary: SDD Framework CLI — initialize and upgrade Spec-Driven Development packs
-Project-URL: Homepage, https://github.com/sunil1983us/universalguide
-Project-URL: Repository, https://github.com/sunil1983us/universalguide
-Project-URL: Bug Tracker, https://github.com/sunil1983us/universalguide/issues
-Project-URL: Changelog, https://github.com/sunil1983us/universalguide/blob/main/CHANGELOG.md
-Author-email: Sunil Kumar <sunil1983.us@gmail.com>
-License: MIT
-Keywords: ai,claude,llm,sdd,sdlc,spec-driven-development,specification
-Classifier: Development Status :: 5 - Production/Stable
-Classifier: Environment :: Console
-Classifier: Intended Audience :: Developers
-Classifier: License :: OSI Approved :: MIT License
-Classifier: Operating System :: OS Independent
-Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.9
-Classifier: Programming Language :: Python :: 3.10
-Classifier: Programming Language :: Python :: 3.11
-Classifier: Programming Language :: Python :: 3.12
-Classifier: Topic :: Software Development
-Classifier: Topic :: Software Development :: Documentation
-Classifier: Topic :: Utilities
-Requires-Python: >=3.9
-Requires-Dist: click>=8.0
-Requires-Dist: keyring>=24.0
-Requires-Dist: pyyaml>=6.0
-Requires-Dist: questionary>=2.0
-Requires-Dist: requests>=2.28
-Requires-Dist: rich>=13.0
-Provides-Extra: diagrams
-Requires-Dist: mmdr>=0.3.0; extra == 'diagrams'
-Description-Content-Type: text/markdown
-
 # sddflow (Python) — SDD Framework CLI
 
 Python CLI for the SDD (Spec-Driven Development) Framework.  
@@ -131,23 +96,40 @@ sdd config init
 ```
 
 Walks through:
-1. Profile name (e.g. `work-cloud`, `on-prem`)
-2. Atlassian base URL
-3. Auth mode — see [Auth Modes](#auth-modes) below
-4. **Credential storage** — system keychain (recommended) or environment
-   variable, see [Credential Storage](#credential-storage) below
-5. Optionally scaffolds `.specify/integrations.yml` — project key,
-   Confluence space key, and parent page ID are filled into your pack's own
-   shipped `.specify/integrations.yml.example`, so every section it
-   documents (`project_keys`, `parent_field_by_level`,
-   `custom_fields_by_level`, `diagrams`, `document_reviews`,
-   `pr_automation`, `code_review`, the full `page_map`) is present from the
-   start, not just the handful the wizard asks about — most stay commented
-   out until you need them. `document_reviews` ships with placeholder Jira
-   accountIds from the example; replace them with real reviewers (or delete
-   entries you don't want routed through Jira) before `sdd review submit`.
-   Falls back to a minimal built-in template only if no `.example` file
-   exists in the project.
+1. **Do Jira and Confluence share the same site and credentials?**
+   - **Yes** (the common Cloud case, one Atlassian site serving both) —
+     collects one profile: name (e.g. `work-cloud`, `on-prem`), Atlassian
+     base URL, auth mode (see [Auth Modes](#auth-modes)), and credential
+     storage (see [Credential Storage](#credential-storage)).
+   - **No** (typical for Server/Data Center, where Jira and Confluence run
+     as separate servers with separate credentials) — runs that same
+     round *twice*, once per service, producing two independent profiles
+     in `~/.sdd/config.yml`. A profile is the entire auth set — base URL +
+     auth mode + credential — not just a URL, so the two are never assumed
+     to overlap even if a base URL happens to coincide.
+2. Optionally scaffolds `.specify/integrations.yml` — project key,
+   Confluence space key, and parent page (ID **or** a pasted page URL —
+   see below) are filled into your pack's own shipped
+   `.specify/integrations.yml.example`, so every section it documents
+   (`project_keys`, `parent_field_by_level`, `custom_fields_by_level`,
+   `diagrams`, `document_reviews`, `pr_automation`, `code_review`, the full
+   `page_map`) is present from the start, not just the handful the wizard
+   asks about — most stay commented out until you need them.
+   `document_reviews` ships with placeholder Jira accountIds from the
+   example; replace them with real reviewers (or delete entries you don't
+   want routed through Jira) before `sdd review submit`. Falls back to a
+   minimal built-in template only if no `.example` file exists in the
+   project. In "No" mode, the top-level `profile:` is wired to Jira's
+   profile and `confluence.profile:` is filled with Confluence's — no
+   manual edit needed.
+
+**Confluence parent page — ID or URL, either works.** Paste whatever
+you have open: a bare numeric ID (`123456`), a Cloud URL
+(`.../spaces/ENG/pages/123456/Page+Title`), or a Server/Data Center URL
+(`...?pageId=123456`) — the numeric ID is extracted automatically. A
+Confluence "tiny link" (`.../x/AbCdEf`) isn't a page ID and can't be
+resolved without an API call; the wizard warns and uses it as-is if you
+paste one — open the page and copy the full URL instead.
 
 ---
 
@@ -176,12 +158,29 @@ sdd config test
 sdd config test --profile on-prem
 ```
 
-Output:
+Without `--profile`, Jira and Confluence are each resolved independently
+through `integrations.yml`'s `jira.profile`/`confluence.profile` (falling
+back to the top-level `profile:` when unset) — so a split-profile setup
+tests each service against its own `base_url`/credentials, not one
+profile's server used for both. An explicit `--profile` always tests that
+one profile against both services, overriding the split — useful for
+sanity-checking a profile before wiring it into `integrations.yml`.
+
+Output (single profile, or no split configured):
 ```
   ✓  Jira       — connected as Jane Smith
   ✓  Confluence — connected as Jane Smith
 ```
 
+Output (Jira and Confluence on separate servers):
+```
+  Jira profile:       jira-dc
+  Confluence profile: confluence-dc
+
+  ✓  Jira       — connected as Jane Smith
+  ✓  Confluence — connected as Jane Smith
+```
+
 ---
 
 ### `sdd config fields`
@@ -355,8 +354,9 @@ What it does:
 3. Ensures a Feature/Epic issue exists for the project — normally already
    created by `/specify` before any spec document exists (see `sdd jira push
    --level epic` below); self-bootstrapped here too as a fallback, refreshed
-   with the BRD's Business Objectives if they weren't available yet — and
-   creates (or updates) a Jira **Story** with the label
+   with the BRD's content (Problem Statement, Business Hypothesis,
+   Description, Out of Scope) if it wasn't available yet — and creates (or
+   updates) a Jira **Story** with the label
    `sdd-doc:{feature}:{doc}`, parented under that Epic and assigned to the
    configured reviewer
 
@@ -971,6 +971,12 @@ profiles:
     pat_env: JIRA_PAT
 ```
 
+A profile is the *entire* auth set — base URL, auth mode, and credential —
+not just a URL. `sdd config init` answering "No" to "same site and
+credentials?" creates two of these (e.g. `jira-dc` + `confluence-dc`) in
+one run, for orgs where Jira and Confluence are separate Server/Data
+Center instances with separate tokens.
+
 ---
 
 ### `.specify/integrations.yml` — project-level, safe to commit
@@ -979,10 +985,13 @@ Wires SDD fields to your Jira project and Confluence space.
 Copy from `.specify/integrations.yml.example` and fill in your values.
 
 ```yaml
-profile: work-cloud     # references a profile in ~/.sdd/config.yml
+profile: work-cloud     # references a profile in ~/.sdd/config.yml -- Jira's
+                         # profile if jira.profile is unset (see below)
 
 jira:
   project_key: MYPROJ
+  # profile: jira-dc     # optional: override the top-level profile for
+                          # Jira calls only (separate Data Center server)
   # Optional: per-level overrides when Features live in one Jira project
   # and Stories/Tasks live in another. Any level not listed falls back
   # to project_key. Valid levels: feature, story, task, review, chg, cr.
@@ -1020,14 +1029,24 @@ jira:
   #     story_points: customfield_99001
 
 confluence:
+  # profile: confluence-dc   # optional: override the top-level profile for
+                              # Confluence calls only (separate Data Center server)
   space_key: ENG
-  parent_page_id: "123456"
+  parent_page_id: "123456"   # bare ID, a Cloud URL, or a Server/DC "?pageId="
+                              # URL all work -- the ID is extracted automatically
   page_map:
     brd:     "{feature} — Business Requirements"
     hld:     "{feature} — High-Level Design"
     runbook: "Runbook"   # living doc -- no {feature}, nests under the Project page
 ```
 
+`jira.profile` / `confluence.profile` let the two services point at
+different `~/.sdd/config.yml` profiles — each falls back to the top-level
+`profile:` when unset, so existing single-profile projects need no
+changes. `sdd config init` wires these automatically when you answer "No"
+to the same-site question; hand-editing is only needed if you're adding
+the split to a project that was already scaffolded single-profile.
+
 Full reference: see `.specify/integrations.yml.example`.
 
 **`project_keys` cross-project caveat:** Jira's parent/Epic-Link field

{sddflow-2.7.92 → sddflow-2.7.99}/pyproject.toml

@@ -4,15 +4,19 @@ build-backend = "hatchling.build"
 
 [project]
 name = "sddflow"
-version = "2.7.92"
-description = "SDD Framework CLI — initialize and upgrade Spec-Driven Development packs"
+version = "2.7.99"
+description = "Spec-Driven Development CLI for AI coding agents — SDLC workflows with Jira/Confluence sync, multi-host PR automation, and live progress dashboards"
 readme = "README.md"
 requires-python = ">=3.9"
 license = { text = "MIT" }
 authors = [
     { name = "Sunil Kumar", email = "sunil1983.us@gmail.com" }
 ]
-keywords = ["sdd", "spec-driven-development", "ai", "sdlc", "claude", "llm", "specification"]
+keywords = [
+    "sdd", "spec-driven-development", "ai", "ai-agent", "sdlc", "claude",
+    "claude-code", "llm", "specification", "jira", "confluence", "atlassian",
+    "pull-request", "code-review", "requirements",
+]
 classifiers = [
     "Development Status :: 5 - Production/Stable",
     "Environment :: Console",

sddflow-2.7.99/sdd/__init__.py

@@ -0,0 +1 @@
+__version__ = "2.7.99"