devlift-cli 0.1.2__tar.gz → 0.1.3__tar.gz

{devlift_cli-0.1.2 → devlift_cli-0.1.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.2
+Version: 0.1.3
 Summary: DevLift command-line tool: create, change, review and deploy DevLift resources from the terminal.
 License: Proprietary
 Keywords: devlift,devops,deployment,infrastructure,cli

{devlift_cli-0.1.2 → devlift_cli-0.1.3}/devlift_cli/__init__.py

@@ -1,3 +1,3 @@
 """DevLift command-line tool."""
 
-__version__ = "0.1.2"
+__version__ = "0.1.3"

{devlift_cli-0.1.2 → devlift_cli-0.1.3}/devlift_cli/skill/SKILL.md

@@ -160,19 +160,29 @@ are in `reference/workflows.md`.
    and prints two tables on stderr: the service (placement, cluster it
    picked, repository, branches, language) and the Configuration table with
    a "From" column saying which values came from the language template.
-3. **Show the user those template values as they were printed and ask:**
-   "These are the standard <language> values. Apply them, or tell me what to
-   change?" That reply is text and ends the turn — no dialog, no tool call,
-   because a dialog would hide the table they are deciding on. Do not rerun
-   with `-y` until they answer.
+3. **Reproduce both tables in your reply, then ask.** Paste them as the
+   command printed them, inside a code block, every row, in the same order,
+   with the "From" column intact. They are the summary. Do not replace them
+   with prose, do not show only the rows you think matter, and do not lead
+   with your own commentary: the user is about to approve these exact values
+   and cannot approve what they cannot see. Anything you want to point out
+   goes AFTER the tables, in a line or two.
+
+   Then ask: "These are the standard <language> values. Apply them, or tell
+   me what to change?" That reply is text and ends the turn — no dialog, no
+   tool call, because a dialog would hide the table they are deciding on. Do
+   not rerun with `-y` until they answer.
 4. A change ("port 9000", "1 GiB memory limit", "turn on autoscaling 2 to 4")
    becomes `--set` flags on the rerun: `--set port=9000`,
    `--set memory_limit=1`, `--set hpa_enabled=true --set min_replicas=2
    --set max_replicas=4`. Rerun without `-y` once more only if the change is
-   large; otherwise rerun with `-y` and report the service, configuration and
-   queue codes.
-5. Say it is a **draft** and name the next step: `request submit`, then a
-   reviewer's `approval approve`, then `eks deploy`.
+   large; otherwise rerun with `-y`.
+5. **Report what is now waiting to be reviewed, not the codes it returned.**
+   Run `devlift request show <service> --env <env> --no-input -o json` and
+   show what it lists: every row in the change set and the fields each one
+   changes. Say it is a **draft**, nothing is deployed, and name the next
+   step: `request submit`, then a reviewer's `approval approve`, then
+   `eks deploy`.
 
 The same show-then-ask shape applies to every write: `eks edit` and the
 update commands print Current | New, `kong route …` prints the route change,
@@ -181,12 +191,57 @@ the approved rows. The summary is printed on every dry run, in json mode too.
 
 ## Reporting back to the user
 
-- After a dry run (exit 5) show the summary the command printed and ask for
-  the go-ahead. After a write, report the codes it returned: resource code and
-  workflow id for resources; queue code and status for drafts and review
-  verbs; workflow id for a deploy.
+- **After a dry run (exit 5), paste what the command printed, verbatim, in a
+  code block**, then ask for the go-ahead. Every row of every table, in order.
+  A summary you wrote yourself is not a substitute: the user is approving the
+  values in that output, so replacing it with "two differences worth your
+  call" hides the other twenty they are also agreeing to. Commentary is
+  welcome after it, never instead of it.
+- **After a draft write, show what will go to review — not the codes.**
+  `eks create`, `eks edit` and `kong route …` all save a draft. The service
+  code, the configuration code and the queue code are plumbing: they belong in
+  your next tool call, not in a sentence a person reads. Run
+  `devlift request show <service> --env <env> --no-input -o json` and report
+  what it lists: every row in the change set, and for each one the fields it
+  changes. A service's settings and its Kong routes are **one change set**, so
+  a route added earlier will be submitted by this submit too, and the user has
+  to see that before they agree to it. Mention a code only if the user asks,
+  or when they need it to run a command themselves.
 - A draft is not deployed. Say so, and name the next command
   (`request submit`, then `approval approve`, then `eks deploy`).
+- **After `request submit`, say three things.** That it is submitted and now
+  waiting for approval. How many rows moved and which kinds (settings,
+  gateway/Kong, variables) — the submit result's `requests[]` gives you both.
+  And who approves it next.
+  For that last one, do not guess and never write "if you have approval
+  rights": run `devlift request show <service> --env <env> --no-input -o json`
+  and read `you.can_approve`. If it is true, say plainly that they can approve
+  it themselves and offer `devlift approval approve <service> --env <env>`. If
+  it is false, say it needs a reviewer on that resource group. The user should
+  never have to work out their own permissions.
+- **After `approval approve`, show the approved change in full.** This is the
+  last checkpoint before anything reaches a cluster, so a queue code and the
+  word "approved" are not enough. Run `devlift request show <service> --env
+  <env> --no-input -o json` and show its frozen diff — every row, Field, From,
+  To — so the user sees exactly what is now cleared to ship. Then read
+  `you.can_deploy` from that same output: if true, say they can deploy it and
+  offer `devlift eks deploy <service> --env <env>` (`--wait` follows it to the
+  end); if false, say a deployer has to run it. Check, never guess, exactly as
+  with approval.
+- **After `eks deploy`, show what is shipping and where it has got to.** Run
+  `devlift deployment status <workflow-id> --no-input -o json` and show its
+  pipeline stages as the command gives them — each stage with its status and
+  timing — so the user can see which step is running rather than reading a
+  sentence about it. Say what is being deployed, which is the change that was
+  just approved, and keep the workflow id visible because every later check
+  needs it. Then name both follow-ups and the difference between them:
+  `deployment status <workflow-id> --wait` says when DevLift's own pipeline
+  finished, and `eks status <service> --env <env>` also asks ArgoCD whether the
+  pod is actually serving, which is the real "is it up" question. A finished
+  pipeline is not a running application.
+- Resources behave differently. `s3`, `sqs` and `dynamodb` create and update
+  deploy straight away, so there report the resource name and the workflow id,
+  which is what `deployment status` needs.
 - On exit 7 quote the message: it names the conflicting request or the rule
   (one live request per service, one auth per Kong tag, a name that exists).
 - On exit 2 stop and tell the user to sign in; on exit 4 say who to ask.

{devlift_cli-0.1.2 → devlift_cli-0.1.3}/devlift_cli/skill/reference/workflows.md

@@ -42,12 +42,18 @@ devlift repositories branches Regobs/orders --no-input -o json | jq -r '.[].name
 devlift languages list --no-input -o json
 devlift eks create --name orders --app core --env stage --region mumbai --type api \
   --repo Regobs/orders --branch main --language go --version 1.24 --no-input -o json 2>&1   # exit 5: two tables (service, configuration with From column) on stderr
-# SHOW the Configuration table to the user and ASK: "These are the standard Go values. Apply them, or tell me what to change?"
+# PASTE BOTH TABLES VERBATIM into your reply, in a code block, every row, before anything else you write.
+# They are the summary — a prose rewrite hides the values the user is about to approve. Commentary goes after them.
+# Then ASK: "These are the standard Go values. Apply them, or tell me what to change?"
 # a change becomes --set on the rerun, e.g. --set cpu_limit=0.5 --set hpa_enabled=true --set min_replicas=1 --set max_replicas=3
 devlift eks create … --no-input -y -o json
 # → {service_code, service_config_code, queue_code, queue_status: "draft", config}
+devlift request show orders --env stage --no-input -o json   # what now waits for review
 ```
-Then tell the user it is a draft and continue with workflow 6.
+Report what `request show` lists — the rows in the change set and the fields
+each changes. Do NOT report service_code / service_config_code / queue_code:
+they are plumbing for your next call, not something a person reads. Then tell
+the user it is a draft, nothing is deployed, and continue with workflow 6.
 `--type worker` drops health/service_path/ALB fields (no load balancer).
 
 ## 4. Change a running service's settings
@@ -74,22 +80,48 @@ the other auth → exit 7: pick another `--tag`.
 ## 6. Review lane (settings and routes move together)
 
 ```
+devlift request show orders --env stage --no-input -o json               # EVERYTHING that submit will send: settings AND Kong routes
 devlift request list --service orders --env stage --no-input -o json     # what exists, statuses, you.can_approve / can_deploy
 devlift request submit orders --no-input -y -o json                      # → requests[] all "submit"; exit 7 if another author holds the lane
+devlift request show orders --env stage --no-input -o json               # after submit: you.can_approve says whether THIS user may approve it
 devlift approval list --no-input -o json                                 # reviewer inbox
 devlift request show orders --no-input -o json                           # frozen diff for the reviewer
 devlift approval approve orders --no-input -y -o json                    # → requests[] all "approved"
+devlift request show orders --env stage --no-input -o json               # after approve: the frozen diff to show, and you.can_deploy
 # alternatives: approval request-changes orders --comment "…" -y ; approval reject orders --comment "…" -y ; approval revoke orders -y ; request withdraw orders -y
 ```
+Before submitting, show the user what `request show` lists and get their
+go-ahead. Submit moves the WHOLE change set, so a Kong route added earlier
+ships with the settings change; someone who only remembers editing CPU must
+not discover the route at approval time.
+
+After submitting, report that it is waiting for approval, how many rows moved
+and of which kinds, and who approves next. Read `you.can_approve` from
+`request show` rather than writing "if you have approval rights" — the CLI
+knows, so the user should not have to.
+
+After approving, show the frozen diff in full (every row, Field | From | To):
+approval is the last checkpoint before a cluster, and "approved" on its own
+tells the user nothing about what they just cleared. Then read `you.can_deploy`
+the same way to say whether they can ship it themselves.
+
 Self-approval works only where the resource group's rule allows it (403 → exit 4 otherwise).
 
 ## 7. Deploy and verify
 
 ```
 devlift eks deploy orders --env stage --no-input                         # lists approved rows, exit 5
-devlift eks deploy orders --env stage --no-input -y --wait -o json       # → {workflow_id, status, state}
+devlift eks deploy orders --env stage --no-input -y -o json              # → {workflow_id, requests[]}
+devlift deployment status <workflow_id> --no-input -o json               # stages with status + timing, pr_url, resources
 devlift eks status orders --env stage --no-input -o json                 # .deployment (stages, pr_url) and .application (ArgoCD state)
 ```
+After deploying, show the pipeline stages as the command gives them, each with
+its status and timing, plus what is shipping and the workflow id. Do not
+replace the stage list with a sentence: the user wants to see which step is
+running. Name both follow-ups and the difference — `deployment status --wait`
+answers "did DevLift's pipeline finish", `eks status` also asks ArgoCD "is the
+pod serving". A finished pipeline is not a running application.
+
 Production: `--confirm-name orders` in place of relying on `-y`.
 Read `.application.state`: `up` = healthy pod; `waiting_for_argocd` /
 `starting` = keep polling (`--wait`); `not_configured` = no ArgoCD for that

{devlift_cli-0.1.2 → devlift_cli-0.1.3}/devlift_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.2
+Version: 0.1.3
 Summary: DevLift command-line tool: create, change, review and deploy DevLift resources from the terminal.
 License: Proprietary
 Keywords: devlift,devops,deployment,infrastructure,cli