NotiOps v1.0.19

NotiOps v1.0.19

This release makes long-term memory actually work. Two separate defects were
keeping it off, and each was silent on its own. The one-click CloudFormation
path never created the memory resource at all, and the code reacts to a missing
memory by continuing without one, so a one-click deployment simply never
remembered anything you had told it in an earlier session. Underneath that, on
both deployment paths, retrieval was discarding every memory it found because
of a relevance threshold set too high for the service's actual similarity scores
— so even the setup.sh path, which has had the memory resource all along, was
storing memories and then never using them. Both are fixed here. The remaining
change is smaller and just as practical: the invitation email a one-click
deployment sends you now contains the sign-in URL, not only a password with
nowhere to type it.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• Long-term memory on the one-click path — it was silently missing. The agent
  is built to remember across sessions through four AgentCore Memory namespaces:
  facts extracted from your conversations, preferences you state, a summary per
  session, and episodes. On the setup.sh path those were created for you. The
  CloudFormation template never created the Memory resource and never injected
  the MEMORY_NOTIOPSWEBCHATMEMORY_ID the agent reads — and an empty value is
  handled by returning "no memory" and carrying on: no error, no log line.
  The feature was absent and invisible at the same time, which is the worst
  combination.

  The template now declares an AWS::BedrockAgentCore::Memory with the same four
  strategies and the same 30-day event-expiry as the setup.sh path, an
  execution role for it, the retrieval and write permissions on the agent's
  runtime role, and a new MemoryId stack output so you can check the wiring
  yourself: the value must equal the MEMORY_NOTIOPSWEBCHATMEMORY_ID environment
  variable on the agent runtime. Extraction is asynchronous — after you state a
  preference, give it a minute or two before starting a new session to see it
  honoured.

  ⚠️ Who shares what. In this release the memory actor is one identity for
  the whole deployment (default-user), so facts and preferences extracted
  from any user's conversations are visible to every signed-in user of the same
  deployment. Session summaries and episodes stay within their own session, and
  chat history remains per user. This is the same on both deployment paths. If
  that is not acceptable for your users, deploy separate stacks. Note also that
  the Memory resource carries no retention policy: deleting the stack deletes
  it and everything accumulated in it.

• The invitation email now tells you where to sign in. A one-click deployment
  creates the admin user in Cognito, which emails a username and a temporary
  password. It did not include the address of the site those credentials are for
  — that was only in the stack's ChatUrl output, which the person who received
  the email frequently could not see. The email now has the subject
  Your NotiOps sign-in details and carries the clickable ChatUrl, the
  username, and the temporary password together. On the setup.sh path the
  deployment summary already printed the URL and the password side by side, so
  both paths now hand over the same three things.

Fixes

• Memory retrieval discarded everything it found — on both deployment paths.
  Each of the four namespaces was queried with a minimum relevance score of 0.5.
  Measured against a real deployment's own records, the service's similarity
  scores do not reach that: a stored preference scores ~0.72 against a near-verbatim
  restatement of itself, 0.41–0.49 against the natural question "what response
  format do I prefer?", and 0.33–0.39 against an unrelated question. Every real
  retrieval was therefore filtered out before it reached the model, and the SDK
  logs retrieved memories only when at least one survives the filter — so the
  symptom was an agent that had memories, found them, and then said it had none,
  with nothing at all in the logs.

  Lowering the number would not have fixed it. A stable preference such as "always
  answer briefly" has to apply to "how do I cut my EC2 bill?", a question with no
  semantic overlap with the preference text, and the gap between relevant and
  irrelevant scores is about 0.02 wide at that boundary — any threshold strict
  enough to filter noise also filters the case the feature exists for. The
  threshold is now off and top_k is the only bound (at most 3+3+5+3 short items
  per turn, ranked by the service). The agent also logs how many memory blocks
  each turn received, including zero, so this class of failure can no longer be
  invisible. This affects the setup.sh path too: re-run it to pick up the fix.

• The automated parity check had this gap recorded as intentional.
  scripts/test_oneclick_parity.py listed "the one-click path has no AgentCore
  Memory" as a deliberate difference, justified by a grep showing that no code
  read MEMORY_*. That grep covered core/ and agent/ — but not
  agent-build/, which is exactly where the code that reads it lives. The
  justification was wrong, and because it was written down as intentional, the
  check actively protected the gap. Two new dimensions now assert the memory
  wiring and the first-login handoff instead, and any future "intentional
  difference" has to be searched for across the agent build tree too.

• Three stale template-size figures in the documentation, two of them in the
  customer-facing one-click guide. The one-click guide also documents long-term
  memory properly now, including the sharing caveat above, what the four
  namespaces hold, the 30-day expiry, and that it goes away with the stack.

Upgrading

setup.sh:

git pull            # or re-clone at tag v1.0.19
./setup.sh          # re-run; existing resources are updated in place

This path already created the memory resource, but it needs this release for the
retrieval fix above — until you re-run setup.sh, memories keep being stored and
never used.

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. The update adds two resources (the
Memory and its execution role) and three permissions on the agent's runtime role.
Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent. This upgrade does not resend the invitation email,
change the admin credentials, revert Admin settings, or clear chat history — and
the new invitation text applies to users created from now on, not retroactively.
An existing deployment starts with an empty memory; nothing is back-filled
from past conversations.

Do not mix assets across releases — the template and the four .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

d86bf4fab38cf40d28ff8ebe7fefae1ac9700b4d41978b9b4bc6af72ac083f3f  bff.zip
7ce8e996d48b1beefaa50636d151ca1c7f6382c51ded6ef5ba573ef3f0c50f02  chat-dist.zip
562440c873bbf88e558ffbf6ef4d8e3ad80204f4404b78a1d996da7167f5ef89  web-notif.zip
2a6f4b19ca77c461058fb813c3a050bbedae528c998db6995ded5b024cb23984  agent-code.zip

Download notiops-webchat.template.json only. The four .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.18

NotiOps v1.0.18

This release is about the wait before the first word. Asking a question after
the chat has been idle used to take 23.4 seconds before anything appeared;
it now takes 10.1 seconds — measured, same account, same prompts. Most of
that came from a bug rather than from physics: long-term memory retrieval was
silently failing on every turn, and four wasted service round trips were sitting
in front of your answer. Both deployment paths upgrade in place; nothing about
your data or your configuration changes.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• First response after idle: 23.4s → 10.1s (−57%). The agent runs on
  Bedrock AgentCore, which isolates by session, so every new conversation is a
  genuine cold start — and before a single tool can be mounted the agent needs
  the tool schemas, which until now meant starting all five stdio MCP servers
  and calling list_tools on each. The slowest one alone measured 9.3s, and all
  of it landed in front of your first token. Three changes, in the order they
  matter:

  1. Memory retrieval no longer wastes four round trips per turn (see
     Fixes — it was also returning nothing).
  2. The five MCP servers start in parallel instead of one after another.
  3. Tool schemas are cached in your own S3 bucket under a new
     mcp-snapshots/ prefix. A new session mounts its tools straight from the
     snapshot and warms the subprocesses in the background, so the startup cost
     no longer sits in the critical path. The object key includes a fingerprint
     of the installed MCP package versions, so upgrading any MCP server
     invalidates the cache by itself — there is no snapshot to remember to
     clear. Reads and writes are both fail-safe: if the snapshot is missing,
     unreadable, or not writable, the agent falls back to today's slower path
     (start the servers first) and still answers correctly. The snapshots hold
     tool schemas only — no conversation content, no account data — and never
     leave your account.

  Measured with scripts/measure_cold_start.py --runs 5, a fresh
  runtimeSessionId per run (reusing a session measures the warm path, ~0.3s,
  not a cold start): general chat 10.14s, FinOps 10.32s, against 23.4s
  before. The very first session after deploying a new runtime version can
  still take ~30s, because the container image has to be pulled once.

• The waiting message tells you the truth again. The heartbeat shown while a
  cold start is in progress said "first request after idle, ~30s". It now says
  ~10s, and the third message still absorbs the long tail rather than quoting a
  worst case at everyone.

Fixes

• Long-term memory was silently retrieving nothing, on every turn. The
  retrieval query is supposed to be your question. What was actually sent was
  the fully assembled prompt — account-isolation rules, topic directive, skill
  body, forced web-search results, language lock — routinely tens of KB. AgentCore
  Memory rejects a searchQuery over 10,000 characters with a
  ValidationException, and the SDK turns that into an empty result list, so
  all four namespaces returned nothing and the failure was invisible: no
  error surfaced, memory simply appeared not to remember anything, and each turn
  still paid for four round trips to find that out.

  The query is now the user's raw question (capped at 4,000 characters), swapped
  in only for the retrieval call so the model still receives the complete prompt.
  Long-term memory across sessions now actually works — if you noticed the
  assistant forgetting things you had told it in earlier sessions, that was this.

• npm test in infra/ could run out of heap. ts-jest builds a TypeScript
  LanguageService over the whole program, including the very large aws-cdk-lib
  type declarations — about 700 MB of heap per suite, while the CDK synthesis
  the tests actually exercise needs only 60–120 MB. On a small CI runner (one
  worker, both suites in one process, ~990 MB default old-space limit) that is a
  hard Reached heap limit — allocation failed crash. The new
  infra/tsconfig.jest.json switches ts-jest to transpile-only: peak heap per
  suite drops from 774 MB to 64 MB and from 799 MB to 117 MB. Type checking
  moves to npx tsc --noEmit -p tsconfig.jest.json, whose include also covers
  test/** — so coverage went up, not down. The memory limit was deliberately
  not raised: a 9× headroom is worth more than a 1.02× one.

Upgrading

setup.sh:

git pull            # or re-clone at tag v1.0.18
./setup.sh          # re-run; existing resources are updated in place

The agent's runtime role gains one permission — s3:GetObject / s3:PutObject
on the mcp-snapshots/* prefix of your existing data bucket — and the snapshot
is built on the first session that runs without one. The IM (Slack / Feishu /
DingTalk) task roles get the same permission, because those containers share the
MCP modules; without it they log AccessDenied and quietly take the slow path,
which works but looks like a fault.

Parallel MCP startup requires strands-agents >= 1.52.0 (earlier versions
patch MCP instrumentation globally without an idempotency guard, so constructing
clients concurrently stacks wrappers). pyproject.toml pins that floor and the
deployment installs it for you; no action needed.

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. Your data is not touched: the
conversation and configuration tables are Retain, and re-seeding is idempotent.
This upgrade does not resend the invitation email, change the admin credentials,
revert Admin settings, or clear chat history.

Do not mix assets across releases — the template and the four .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

5d9c8b3248f752c530b03fc60c8a8b881661b1ac51b60292d1f64a2e5bb05fe7  bff.zip
f44e48fc03eceeb02cb62f111b0ecdd66c6a72a996879558b33195f750ae10cd  chat-dist.zip
562440c873bbf88e558ffbf6ef4d8e3ad80204f4404b78a1d996da7167f5ef89  web-notif.zip
d77c924a6d11898db9c46d85bb4b51273b92b6cf41b1965bde82284782ddc5c8  agent-code.zip

Download notiops-webchat.template.json only. The four .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.17

NotiOps v1.0.17

This release is about the deployment finishing on its own. Creating an Agent
Space now also enables its operator web app, so nobody has to find the
Configure web app button in the console — and without that button, four
DevOps Agent capabilities used to fail with an error that never mentioned it.
The other half is a one-click fix that mattered more than it looked: in any
account that had ever run setup.sh, the one-click stack failed entirely, in
about nine seconds, over a log group name. Both deployment paths upgrade in
place.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• The DevOps Agent operator web app is enabled for you. Deploying used to
  leave one manual step behind: open the console, go to Agent Space → Access →
  Operator access → Configure web app, and click it. Skip it and the Agent
  Space has no https://<spaceId>.aidevops.global.app.aws domain, so
  CreateChat / CreateBacklogTask answer Invalid or unregistered domain and
  four capabilities die together — deep investigation, deep investigation
  (direct), DevOps Chat, and publishing a Skill to your DevOps Agent — while the
  error says nothing about a button you did not press.

  The Agent Space resource now carries the operator app configuration directly,
  along with the role it needs, so all three paths that create a space do
  this at create time:

  • the one-click CloudFormation stack,
  • setup.sh,
  • and the member-account StackSet — the biggest win, because a multi-account
    customer previously had to log into every member account and click it once
    per account.

  Only the iam authentication flow is configured (the BFF connects with
  SigV4); IAM Identity Center and external IdPs are left for you to choose.
  Deleting the stack disables the operator app on the way out. The one-click /
  setup.sh parity test has a new criterion that pins all three paths, so this
  cannot silently regress on one of them.

  Upgrading an existing deployment: if your Agent Space already exists and
  its web app was enabled by hand in the console, this template change asks
  CloudFormation to enable an already-enabled app. That path is not verified —
  it may be a no-op or it may conflict. If it conflicts, run
  aws devops-agent disable-operator-app --agent-space-id <id> and deploy again;
  the domain is derived from the space id, so turning it off and on does not
  change your URL. New deployments are unaffected.

Fixes

• One-click deployment failed for the whole stack in any account that had ever
  run setup.sh. The stack died in about nine seconds with a single line:

  Resource of type 'AWS::Logs::LogGroup' with identifier
  '/aws/lambda/notiops-web-notif-handler' already exists.
  

  (and only aws cloudformation describe-events shows even that much —
  describe-stack-events just says Validation failed with 1 error(s)).

  The name collision was not the whole story: a /aws/lambda/<function> group is
  also created by Lambda itself, and the one Lambda creates belongs to no
  stack — it never expires and it survives stack deletion. So one earlier
  setup.sh run in an account was enough for CloudFormation's
  NAME_CONFLICT_VALIDATION pre-check to reject every later one-click
  deployment, with nothing in the message tying it to notifications.

  The notification handler's log group is no longer named — CloudFormation names
  it and the function points at it through LoggingConfig, the shape the BFF
  already used. That also fixes the thing the hard-coded name was there for: the
  function writes only to this group and no longer creates a second one on first
  invocation. Both deployment paths are fixed, and the release gate now refuses
  to emit a template containing any hard-coded LogGroupName (names that
  include the stack name are allowed — those are unique per stack).

  Already-deployed setup.sh environments keep the old orphan group after
  upgrading (old logs are still there, still never expiring); delete it by hand
  if you want it gone.

• The one-click parameter undersold what it controls. The Agent Space that
  EnableDeepInvestigation creates carries four capabilities — deep
  investigation, deep investigation (direct), DevOps Chat, and publishing a Skill
  to your DevOps Agent — but the console label only said "deep investigation".
  Customers chose No expecting to lose one feature and lost DevOps Chat as
  well: greyed out, no error, the hardest kind to diagnose. The label now reads
  Enable AWS DevOps Agent features (deep investigation, DevOps Chat)? and the
  description names all four plus what No costs you. The parameter name is
  deliberately unchanged — renaming it would drop the value when an existing
  stack is updated.

• The "Escalate to AWS Support" shortcut button after an investigation is
  hidden. The capability is untouched: the tool is still registered and still
  routed, so asking in plain language ("open a support case for this") works
  exactly as before.

Docs

• One-click deployment §6.1 contained a
  promise that does not hold. KeepData was described as leaving your data for
  the next deployment to pick up; it does not, because the table and bucket names
  are fixed and CloudFormation's name-conflict pre-check fails the entire
  stack before creating a single resource. Verified with a two-line probe stack.
  KeepData is for keeping data in place to export or examine, not for
  redeploying on top of it — the stack cannot adopt tables that already exist.
  §6.4 now says plainly that you must delete those tables first if you intend to
  redeploy. §2.7 gains a note on the operator app, §3's resource count moves
  65 → 66, and §6.3 carries measured teardown times for both modes instead of
  claiming they are the same.
• Which notification sources are on by default was backwards in four
  documents. It is: on — AWS Health, CloudWatch Alarm, Cost Anomaly, Trusted
  Advisor, GuardDuty; off — Backup, EC2 Spot, Auto Scaling, RDS, Config. The
  user guide also now says the two things a reader
  actually needs: three of the on-by-default sources only produce events once you
  enable the corresponding service (until then the rule is enabled but silent —
  harmless, no cost, effective the moment you enable it), and how to turn on the
  off-by-default ones on each path.
• Deployment has a new §5.3.3 on the operator app,
  including the upgrade caveat above.

Upgrading

setup.sh:

git pull            # or re-clone at tag v1.0.17
./setup.sh          # re-run; existing resources are updated in place

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. This upgrade replaces the
notification handler's log group with a CloudFormation-named one; it does not
resend the invitation email, change the admin credentials, revert Admin settings,
or clear chat history.

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent.

If your deployment already has an Agent Space whose web app you enabled by hand,
read the upgrade note under Features before updating.

Do not mix assets across releases — the template and the four .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

b80f66fd5b73f4524796c1b3e36943f9e25171f13948db92634b280820e9548a  bff.zip
ed74863e3aa1bec38c0a8cf1b0977dd0d358adb624eaae7b0b5bd66ddc4e5109  chat-dist.zip
562440c873bbf88e558ffbf6ef4d8e3ad80204f4404b78a1d996da7167f5ef89  web-notif.zip
727acc3ef34c51635d9dc3797c1edc5054715646a43cd57b5fb804aeafb1bce0  agent-code.zip

Download notiops-webchat.template.json only. The four .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.16

NotiOps v1.0.16

This release is about who answers. A new general chat now opens with a
conversation-object picker: keep talking to NotiOps, or hand the whole
conversation to your own AWS DevOps Agent, which answers directly — the BFF
talks to its control plane, so no Bedrock model is involved, nothing is billed to
the deployment's model capacity, and NotiOps reports 0 tokens for those turns.
The other half of the release is a parity fix: on the one-click (CloudFormation)
path the Notifications inbox was always empty — the producer side simply did
not exist there. Both deployment paths upgrade in place.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• DevOps Chat — pick who answers a general chat. Starting a chat outside any
  topic now shows a two-segment control: NotiOps (default) or your DevOps
  Agent. Choosing the second one makes every turn in that conversation go
  straight to your own agent:

  • No model, no token cost on our side. The turn does not go through Bedrock
    or the NotiOps agent runtime; the BFF calls the DevOps Agent control plane
    (CreateChat / SendMessage) and streams the reply back. Usage counts
    against your DevOps Agent, and NotiOps reports 0 tokens for the turn. This
    also means the path works on a deployment where no Bedrock model has been
    enabled yet.
  • It reads like the agent's own page. Text is forwarded delta by delta, not
    buffered into blocks, and a transient progress line covers the first seconds
    before the answer starts. Multi-turn context is kept per conversation.
  • The choice is skippable and then fixed. Not choosing anything and just
    typing means NotiOps, exactly as before. After the first message the object
    is locked for that conversation (a tag in the header says which one), because
    the two sides have different answerers and different tool sets — switching
    mid-conversation would silently change what the history means.
  • The toolbar slims down to what actually applies: no web search, no model
    selector, and one per-turn checkbox — Deep investigation. Unchecked you
    get streaming Q&A; checked, the same turn runs your agent's full multi-signal
    root-cause investigation and returns a report (minutes, not seconds). The
    / skill menu works here too: the Skill body is inlined into the message
    that is sent, so nothing needs to be published first.
  • Read-only posture is preserved. If your agent is waiting for a human
    approval, NotiOps says so and points you at the DevOps Agent console; it
    never answers a pending approval on your behalf — that API is neither called
    nor granted.
  • Prerequisite: the account has to be onboarded to a DevOps Agent Agent
    Space. If it is not, the segment is greyed out and says why.

  The new permissions live in the construct shared by both deployment paths, so
  one-click and setup.sh get this identically.

• Notifications now work on the one-click path. The inbox page used to be
  permanently empty there: the read side was shared between the two paths, but
  the producer (EventBridge rules → Lambda → the inbox table) only existed in the
  setup.sh stack — with no error, no log line, and nothing in the stack outputs
  to hint at it. The 10 signal sources (AWS Health, CloudWatch alarms, Cost
  Anomaly, Trusted Advisor, GuardDuty on by default; Backup, EC2 Spot
  interruption, Auto Scaling launch failure, RDS, Config off by default) are now
  a single shared module that both stacks import, and a new artifact,
  web-notif.zip, ships with the release (the one-click stack downloads it the way
  it already downloads the other three).

  Turning an individual source off differs by path, on purpose: setup.sh takes
  -c webNotif<Id>=off at synth time, while on the one-click path you disable
  that EventBridge rule in the console — the template does not manage rule
  enablement, so your change survives a template upgrade.

• The / menu lists every Skill, not a truncated set: a count in the header,
  scrolling, filtering by id or name, arrow keys plus Enter, and a note on each
  of the three DevOps Agent paths saying that your agent — not NotiOps — is what
  executes the Skill.

• The BFF Lambda runs on Node.js 24 (was 20).

Fixes

• Already-deployed environments never received newly added models. Both
  catalogue seeders wrote with attribute_not_exists(PK) — write once, never
  again. The first deployment stored the catalogue as it was that day, and every
  model added later was invisible to that environment: no error, no log, just one
  fewer entry in Admin → Models and in the model selector. GLM 5 went missing
  exactly this way. Seeding is now additive: it tops up entries the catalogue has
  and the table lacks, and does not touch your enabled set or your default model
  — a top-up must never quietly switch a new model on for you. Both paths are
  fixed, and the one-click stager was granted the reads/updates it needs to do it.

• The default chat model is Claude Sonnet 5 again for new deployments and new
  conversations. Grok 4.6 is still in the catalogue and still selectable; it is
  just no longer the default.

• Three display bugs in the new DevOps Chat path, all of the "no error, wrong
  pixels" kind: the answer could be printed twice (the terminal event carries the
  accumulated text, which was appended to what had already streamed), the bubble
  could stay empty when the agent asked a clarifying question instead of
  answering, and tool arguments could flash through the investigation panel as
  raw JSON.

• Clicking "Investigate" on a notification did not tick the direct
  deep-investigation box, so that turn silently went through the model-rewriting
  path instead.

• Coming back to a topic left your previous question sitting in the composer.

• Appearance fixes: the selected conversation-object segment in both light and
  dark themes, the header tag (it used to be a bright patch in dark mode), the /
  menu now aligning with the composer and sharing its background, the account chip
  in a reply's footer losing its stray border, and the footer collapsing into a
  single line. The disclaimer under a DevOps Agent answer now names the DevOps
  Agent rather than NotiOps.

Docs

• User guide (EN) has a new
  section on picking a conversation object — what each side is good at, what it
  costs, and the fact that the choice locks — plus the difference between the two
  ways to launch a deep investigation, who executes a Skill on each path, and a
  corrected model list and / menu description.
• Technical design
  (EN) documents the three paths that hand a turn
  to your DevOps Agent side by side, why the control plane is used instead of the
  agent's MCP/A2A tool surface, and the streaming contract.
• One-click deployment
  (EN) now lists all four capabilities that
  the Agent Space parameter unlocks, and notes that two of them are the fastest
  way to get value out of a deployment with no Bedrock models enabled yet.
• New Web console screenshots in the README.

Upgrading

setup.sh:

git pull            # or re-clone at tag v1.0.16
./setup.sh          # re-run; existing resources are updated in place

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. This upgrade adds the notification
EventBridge rules and their Lambda to your stack; it does not resend the
invitation email, change the admin credentials, revert Admin settings, or clear
chat history.

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent — the model catalogue top-up adds missing entries
only.

If you want DevOps Chat or either deep-investigation path, set
EnableDeepInvestigation to yes — the four DevOps Agent capabilities all
share the one Agent Space that parameter creates. Left at no, those controls
stay greyed out and the rest of the product is unaffected.

Do not mix assets across releases — the template and the four .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

8d429001fec50f6565916b6d2913ca39d8e85df7712a016f897024540dbdf01d  bff.zip
4dac3050aa37ba831267461092d39e12bf771dde7a7fe4853d2aff6d4087f047  chat-dist.zip
562440c873bbf88e558ffbf6ef4d8e3ad80204f4404b78a1d996da7167f5ef89  web-notif.zip
7092306f5fa59c9b3eb008b1369f48e6a06593aa17f10530b21f44851a80de9e  agent-code.zip

Download notiops-webchat.template.json only. The four .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.15

NotiOps v1.0.15

This release is mostly one bug. On the ./setup.sh path a deployment could
finish reporting success while Web Chat answered every question by echoing it
back — Got it — you said: "…" (Echo — AGENT_RUNTIME_ARN not set). The agent had
never actually deployed, and nothing in the output said so. If you are on
setup.sh, take this release. Whether you are affected depends on the day
you ran the installer, which is exactly why it is worth fixing properly rather
than documenting. Four one-click-path and Admin defects are fixed too, all of
the same silent kind: the feature was simply empty or missing, with no error
anywhere.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Fixes

• setup.sh could finish green while Web Chat only echoed. Two independent
  causes with the same end state, and the same reason it was invisible: the agent
  deploys before the web tier, a failure there printed one ⚠ line, and the
  rest of the install carried on and succeeded. With no agent runtime ARN the BFF
  falls back to echoing.

  1. uv was never checked for. The AgentCore CLI shells out to uv to
     package the agent's Python dependencies — without it that step cannot
     succeed. uv is now a preflight prerequisite in both setup.sh and
     scripts/deploy_agent.sh, with install instructions, and it is documented as
     a prerequisite in the README.
  2. The AgentCore CLI version was not pinned. npm install -g @aws/agentcore
     installed that day's latest. A newer CLI's deploy step rewrites the
     repository's own CDK harness pin (@aws/agentcore-cdk) to a version whose
     API no longer matches the checked-in CDK stack, so the TypeScript build fails
     in about ten seconds, no CloudFormation stack is created, and there is no
     runtime ARN. It also does not heal on a retry, because the rewritten
     package.json persists — and downgrading the CLI alone is not enough for the
     same reason. The version is now pinned to a validated release, and both drift
     states (wrong CLI version, rewritten harness pin) stop the deployment and
     print exactly what to run, instead of degrading to echo. agentcore deploy
     failures now also print the CLI's own step log, where the real compiler error
     lives.

  Already have an echoing deployment? One command repairs it — it diagnoses
  read-only first, shows you the plan, and only then changes anything:

  bash scripts/fix_web_chat_echo.sh --region <your-region>

  It restores the harness pin, installs the validated CLI, redeploys the agent,
  injects the runtime ARN into the BFF, and verifies the result. Live settings
  (multi-account mode, allowed origins) are read back from your deployment first,
  so the repair cannot quietly downgrade them. Add --diagnose to look without
  touching anything.

• One-click: Admin → Models showed an empty table. The setup.sh path seeds
  the model catalogue after deploying; the one-click path never did, so the Admin
  model page listed nothing — not even the default model — while chat itself
  worked, because the frontend carries a built-in fallback list. The stack now
  seeds the catalogue, with a conditional write: anything you have already changed
  in Admin is never overwritten, and updating an existing stack backfills the seed.

• One-click: updating an existing multi-account stack applied no fixes to the
  multi-account setup. Every property of that custom resource was static, so
  CloudFormation saw no change and never invoked the handler — meaning handler
  fixes shipped in a new template reached new stacks only.

• The factory default model could not be saved in Admin → Models. Saving
  probes the default model with a real request, and the probe asked for only 8
  output tokens — below Grok 4.6's minimum. The resulting validation error was
  classified as "this model is broken" and the save was rejected. The probe now
  asks for 64, and "the request asked for too few output tokens" is no longer
  blamed on the model.

• Dashboard AI insights were silently empty in two cost views and one support
  view. Those three requests passed temperature: 0, which Claude Sonnet 5 no
  longer accepts, so every call failed — and the error was swallowed into a
  generic "no insight" state. The parameter is gone and the request shape is now
  covered by tests.

Features

• GLM 5 (zai.glm-5) is selectable in Web Chat, alongside Claude Sonnet 5 /
  Opus 5 / Haiku 4.5, Amazon Nova Pro, DeepSeek V3.2, the GPT-5.6 family, and
  Grok 4.6. Enable it in Bedrock → Model access if you want it.

  Note it has no cross-Region inference profile, so it only exists in the
  Regions it has shipped to — measured available in us-east-1, us-west-2 and
  ap-northeast-1, and absent in ap-southeast-1, eu-west-1 and
  eu-central-1. DeepSeek V3.2 has the same property. That is why the default
  model stays Grok 4.6 (global.xai.grok-4.6): a default has to work in
  whichever Region you deploy into, and a Region-limited default fails on the
  first message with nothing but an AccessDeniedException to go on.

Upgrading

setup.sh:

# uv is now a prerequisite — install it first if you do not have it
curl -LsSf https://astral.sh/uv/install.sh | sh   # or: brew install uv / pipx install uv

git pull            # or re-clone at tag v1.0.15
./setup.sh          # re-run; existing resources are updated in place

If your current deployment only echoes, run scripts/fix_web_chat_echo.sh (see
above) rather than re-running the whole installer — it is faster and it verifies
the outcome.

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. Upgrading does not resend the
invitation email, change the admin credentials, revert Admin settings, or clear
chat history.

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent.

Do not mix assets across releases — the template and the three .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

dca5b802fd5deb17496fa750593f45176820c120bedeeec3b91f7d2adda2d073  bff.zip
542651bc7efa71614b8999436bd5b2b16660f56cad4b28e86983b096c88a0bc4  chat-dist.zip
f8f6ba0be5b9ff97e3bac20862e1c4a0263c0d5bf47d529c30ae0b4b3eb9205d  agent-code.zip

Download notiops-webchat.template.json only. The three .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

v1.0.14

NotiOps v1.0.14

A teardown-path patch on top of v1.0.13. Deleting a deployment had two
defects: one made the stack delete fail outright, and one silently left a
resource behind while reporting success. Nothing here changes a running
deployment — if you are not deleting anything, there is no urgency to update.
But "try it, then delete it" is the most common thing anyone does with a sample
repo, so this is worth taking.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Fixes

• Deleting the stack with TeardownMode=DeleteEverything could fail on the
  data bucket. Right after a bucket is emptied, S3 frequently rejects the
  immediately-following DeleteBucket with OperationAborted — "a conflicting
  conditional operation is currently in progress against this resource" — because
  the batch of object deletions is still settling. On this path the error is
  deliberately allowed to propagate (you asked for everything to be deleted;
  quietly keeping your data would be worse than stopping), so with no retry the
  stack went straight to DELETE_FAILED. Deleting the stack a second time
  succeeded, which is exactly why this is easy to write off as a one-off. The
  delete is now retried for up to 30 seconds.

• The stack silently failed to delete the web-search gateway it had created.
  Deleting a gateway target is asynchronous: the DELETE returning success only
  means the deletion started. Teardown deleted the target and immediately
  deleted the gateway, which the service rejects while a target is still
  attached — and on the teardown path that error is swallowed on purpose (leaving
  one orphan behind is better than wedging your whole stack in DELETE_FAILED).
  The result was a silent failure: the stack deleted cleanly and reported
  success, while an AgentCore gateway named notiops-websearch-gw stayed behind
  in READY, contradicting what the documentation promises. Teardown now waits
  for the targets to actually be gone before deleting the gateway.

  If you deployed v1.0.13 in us-east-1 and have already deleted the stack,
  check for a leftover gateway — it is tagged project=notiops:

  aws bedrock-agentcore-control list-gateways --region us-east-1 \
    --query "items[?name=='notiops-websearch-gw']"
  # if it is there and nothing else uses it:
  aws bedrock-agentcore-control delete-gateway --region us-east-1 \
    --gateway-identifier <gatewayId>

  An orphan cannot serve searches (its target was deleted) and is not billed for
  being idle, so this is hygiene rather than cost. Note that a later redeploy
  finds the same-named gateway and reuses it, so nothing stays broken.

• The v1.0.13 "replace a FAILED gateway" fix rested on the same faulty
  helper. It shares the delete routine above, and on that path the error is
  raised rather than swallowed — so instead of leaking a resource, provisioning
  degraded to WebSearchProvisioning: unavailable (…) whenever the dead gateway
  still had a target attached. Fixed by the same change.

• setup.sh had both bugs too. teardown.sh and
  scripts/provision_websearch_gateway.sh used the same delete-then-immediately-
  delete sequence, each with the failure suppressed, so they were just as silent.
  Both now wait for the targets to disappear.

Upgrading

Nothing about this release affects a running deployment, so you only need it
before you next delete one — but the fix has to be in the stack before the
delete, because CloudFormation hands a custom resource the values from the last
successful deployment, not the ones you wish it had at delete time.

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below and update your stack with it — Replace existing template, then
Use existing value for every parameter. Upgrading does not resend the
invitation email, change the admin credentials, revert Admin settings, or clear
chat history.

setup.sh:

git pull            # or re-clone at tag v1.0.14
./setup.sh          # re-run; existing resources are updated in place

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent.

Do not mix assets across releases — the template and the three .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

f4ece748f4f0643d344e991a1196562edb2cb56d418aab84475f22554a00d714  bff.zip
f23d5c94991422bae16c11c81dcb60457f677526b667f0cb18c0e8baf06da2f6  chat-dist.zip
2ac1b628cfc23954348c6c7438775c2e3cbb4deea230d31a0bcfa55edd1b1623  agent-code.zip

Download notiops-webchat.template.json only. The three .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.13

NotiOps v1.0.13

The two deployment paths now install the same web console. Both paths have
always shipped the same agent, the same frontend, and the same BFF — the only
difference was supposed to be who creates the resources. In practice the
one-click stack was missing the web-search gateway and the IAM that goes with
it, so the
web-search toggle in the chat input bar rendered and clicked but never
returned anything. This release closes that gap, adds a CI check that fails the
build if the two paths drift again, and makes web search AWS-native on both
paths (no third-party API key, and the query text never leaves AWS).

If you deployed with the one-click template, update your stack to get web
search — see Upgrading.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• Web search on the one-click path. The stack now creates the Bedrock
  AgentCore gateway (notiops-websearch-gw) with the AWS built-in web-search
  connector target, and grants the agent runtime bedrock-agentcore:InvokeGateway
  — the two things the toggle needed. There is no parameter to fill in: no
  API key, no endpoint, nothing to configure. Billing is per search, so it only
  costs anything when a user turns the toggle on and the agent decides to
  search.

  Two behaviours worth knowing:

  • us-east-1 only. That is where the AgentCore web-search API is
    available today. Deploying into any other Region still succeeds — the
    web-search resources are skipped as a block and the new WebSearchStatus
    stack output tells you why. Note the toggle is not greyed out in other
    Regions (the UI does no Region check): clicking it does not error, you just
    get no results.
  • Two outputs, because "the Region supports it" and "it actually got
    built" are different questions. WebSearchStatus answers the first;
    the new WebSearchProvisioning output answers the second — enabled
    means the toggle works, unavailable (<code>) means it does not.
    Provisioning deliberately never fails the stack (losing every other
    feature over one optional toggle would be a bad trade), which is exactly
    why the result needs its own output.
  • An existing gateway is reused, not duplicated — and not deleted. If the
    account already has a notiops-websearch-gw (for example because you ran
    ./setup.sh first, or you have a second stack in the same account), the
    stack reuses it. Whether it created or reused is recorded, and deleting the
    stack only removes a gateway that this stack created. Tearing down one
    deployment does not break another one that is still using it.

• Web search is AWS-native only; the third-party fallback is gone. Both
  paths previously fell back to a public third-party search endpoint when the
  AWS-native gateway was unavailable, which meant the query text could leave
  AWS and, on the one-click path, required you to bring your own API key. That
  fallback has been removed from both paths. Web search is now exactly one
  implementation — the AgentCore web-search connector — so "web search is on"
  has a single, checkable meaning. If the gateway is not configured for a
  deployment, web search reports itself as unavailable instead of quietly
  routing your query somewhere else.

Fixes

• A deployment without a working gateway now says "no web search" instead of
  timing out on every search. The gateway URL is only accepted if it starts
  with https://; anything else counts as "not configured". Previously the two
  values that actually turn up there — the un-substituted
  __WEBSEARCH_GATEWAY_URL__ placeholder you get from running agentcore deploy
  by hand instead of scripts/deploy_agent.sh, and the unavailable marker the
  one-click stager writes when it could not provision the gateway — were treated
  as real endpoints, so each search SigV4-signed a request to a garbage host and
  waited out the HTTP timeout.
• The scaffold that actually gets deployed said web search used a third-party
  engine. That note reached the model in a tool description, so the assistant
  could tell a user their query had left AWS when it had not. It now matches
  reality.
• The one-click stack could not finish building the gateway it created. The
  role that provisions it was missing bedrock-agentcore:CreateWorkloadIdentity
  on the account's default workload-identity directory. CreateGateway returns
  success without it and the gateway then goes FAILED asynchronously —
  "Failed to create gateway dependencies" — so the stack reached
  CREATE_COMPLETE next to a dead gateway. setup.sh never hit this because it
  provisions with the deployer's (usually administrator) credentials.
• A gateway stuck in FAILED is now replaced instead of reused forever.
  Both paths look up the gateway by name and reuse what they find, which turned
  one bad first attempt into a permanent condition: every later deploy waited
  for the same dead gateway to become ready. A FAILED gateway cannot serve
  anything, so both paths now delete it and build a new one. Gateways in any
  working state are still reused untouched.
• setup.sh no longer hands the agent a gateway URL that does not work. If
  the gateway never reaches READY, scripts/provision_websearch_gateway.sh
  now fails loudly (pointing at statusReasons and the permission above)
  instead of printing the URL anyway. The deployment continues without web
  search, which is the honest outcome — previously the agent was configured
  with a URL that timed out on every search.

Docs

• docs/DEPLOYMENT_ONECLICK.md / .en.md: web search moved out of the "not
  included" list into its own section covering billing, the us-east-1
  restriction, and the reuse/delete semantics; WebSearchStatus and
  WebSearchProvisioning added to the outputs table; the resource count corrected to 50 with the default
  parameters (+3 in us-east-1, −4 with deep investigation off, +3 for
  multi-account), and the rows for the reports CDN and the web-search resources
  filled in.
• README feature comparison: a web-search row, and two corrections where the
  one-click column understated it — Bedrock API key as the credential and
  permanent links for long reports are both supported on the one-click path
  (the secret is created on demand by the BFF on either path, and the reports
  CDN is inside the stack).
• docs/USER_GUIDE.md / .en.md: the web-search toggle only does something in
  us-east-1, so a user who gets no results knows it is a deployment Region
  question, not a broken assistant.

Under the hood

• A new source-level check asserts that the agent runtime execution role gets
  the same set of IAM actions and the same set of injected environment
  variable keys on both deployment paths, with wildcard awareness
  (ce:List* covers ce:ListCostAllocationTags). It fails loudly if it cannot
  locate the sections it compares, rather than passing silently — a check that
  can't find its input is not a passing check. The list of Regions the agent may
  reach is likewise asserted to be identical on both paths: "supported on both
  paths, but in different Regions" is its own kind of drift.

Upgrading

One-click (CloudFormation): download notiops-webchat.template.json from
the assets below and update your stack with it — Replace existing template,
then Use existing value for every parameter — a template update of this kind
takes a couple of minutes. In us-east-1 it adds the web-search gateway; in
other Regions the web-search resources stay skipped. Upgrading does not resend the invitation email, change the
admin credentials, revert Admin settings, or clear chat history.

setup.sh:

git pull            # or re-clone at tag v1.0.13
./setup.sh          # re-run; existing resources are updated in place

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent.

Do not mix assets across releases — the template and the three .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

7f970584ece8527dcdf4649dd8f39a0c50242f14b858be1b8e82364f9b54de2f  bff.zip
83ffe7b2439b01e275de1d608d02de8195acc6c6442fd2076d159a5cb5cec969  chat-dist.zip
88448ea790397c68edce183e19a29e235fb3b739e0a9d4e0c17b1de0502784ba  agent-code.zip

Download notiops-webchat.template.json only. The three .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is above CloudFormation's 51,200-byte
--template-body limit — from the CLI, upload it to S3 first and pass
--template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.12

NotiOps v1.0.12

Uninstalling is now as much of a one-liner as installing. The one-click path has
had a TeardownMode parameter since v1.0.10, but the setup.sh path left you to
cdk destroy five stacks in the right order and then hunt down the things CDK
never owned. This release adds teardown.sh, and corrects a feature
comparison table that understated what the one-click path can do.

There are no changes to the application itself in this release — the agent,
BFF, frontend, and CloudFormation template are functionally identical to
v1.0.11. If you are running the one-click stack, there is nothing you need to do.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• ./teardown.sh — remove everything setup.sh created, in one command.
  Two tiers, mirroring the one-click stack's TeardownMode:

  ./teardown.sh --dry-run            # inventory only, deletes nothing
  ./teardown.sh                      # keep data: delete stacks and runtimes, keep the three Retain'd tables
  ./teardown.sh --delete-everything  # also delete the tables, CUR report/bucket, Athena saved queries, orphaned log groups

  It deletes in reverse dependency order and covers the leftovers that
  cdk destroy does not, each of which breaks a later reinstall or quietly keeps
  costing money if missed:

  • the CUR report definition and the CUR bucket (a report definition is a
    Billing-console resource, not a stack resource);
  • the one-shot EventBridge schedule that finalizes the first CUR export;
  • the WebSearch AgentCore gateway, its targets, and its IAM role;
  • the 30-day recovery window on Secrets Manager secrets — a plain delete
    only schedules deletion, so a same-name redeploy fails with a conflict
    until the window expires. The script force-deletes instead.

  Confirmation is required by typing the 12-digit account id, and
  --delete-everything additionally asks you to type DELETE EVERYTHING. Every
  phase is idempotent: if a stack deletion fails, the script prints the failing
  DELETE_FAILED events and you re-run it.

• It refuses to delete resources that belong to a different deployment. Both
  deployment paths use the same physical resource names (notiops-config,
  notiops-data-<account>-<region>, and so on), so on an account where both have
  been installed, "empty the data bucket" is genuinely ambiguous. Before emptying
  a bucket or deleting a table, the script asks CloudFormation which stack owns
  it and skips anything owned by a stack it did not create — telling you
  which stack to delete instead. Verified against a live one-click stack sharing
  those names.

• The data bucket is backed up locally first, by default. On the setup.sh
  path notiops-data-<account>-<region> is destroyed with the stack — your
  Skills and saved reports live there, and unlike the one-click path there is no
  "keep data" setting that can protect it. So the default is to s3 sync it to a
  local directory before deleting; --backup-dir chooses where, --no-backup
  opts out.

• Cross-account resources are deliberately left alone. The member-account
  StackSets and the per-account AWS Health event forwarders reach into accounts
  other than the one you are running in, so the script prints the exact commands
  and stops, rather than deciding for you: --delete-member-stacksets opts into
  removing the StackSets, and the PHD forwarders come out with
  ./setup.sh --phd --remove. Shared infrastructure — the CDK bootstrap stack
  and its buckets, the cid_cur Glue database, the Security Hub aggregator — is
  never touched.

Docs

• The one-click column of the feature comparison table was wrong in three
  places. Deep investigation, publishing a Skill to AWS DevOps Agent, and
  multi-account inspection are all supported on the one-click path, and have been
  since v1.0.11 — the table still showed them as setup.sh-only. All three now
  read ✅, with a footnote covering what they actually depend on: one Agent Space,
  created only when EnableDeepInvestigation=Yes and the deploy Region is one
  where AWS DevOps Agent is available. In other Regions the stack still deploys,
  the related toggles are greyed out with the reason shown, and the
  DeepInvestigationStatus output tells you which case you are in.
• The "Web Search (Exa)" row is gone. It described a capability that requires
  a third-party API key you supply yourself, which made it read as a product
  feature rather than an optional integration.
• One-click deploy time is stated as about 5 minutes rather than a
  false-precision figure from a single measurement.
• Both docs/DEPLOYMENT.md and its English version now point at teardown.sh
  from the stack-deletion section, instead of implying stack-by-stack
  cdk destroy is the way to remove an installation.

Fixes

• A golden test asserted against a hardcoded real AWS account id; it now uses a
  placeholder. Test fixtures are not a place for account numbers.

Upgrading

One-click (CloudFormation): nothing to do — this release contains no
application changes. If you want your stack tagged to the current release anyway,
download notiops-webchat.template.json from the assets below and update the
stack with it (Replace existing template, then Use existing value for
every parameter).

setup.sh:

git pull            # or re-clone at tag v1.0.12
./setup.sh          # re-run; existing resources are updated in place

Your data is not touched: the conversation and configuration tables are Retain,
and re-seeding is idempotent.

Do not mix assets across releases — the template and the three .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

3ab8ff61cf326df49851d1af2ee24b7c28074ab65db41e022737050258b1d5df  bff.zip
c082239e0bed5f5742cb66c599d83eb8bddb9fec78441e7803866e9e737b5e39  chat-dist.zip
0789cd3fe0253c8440f0e96a8552ed990bdab18e880ce823bf2f27df186e7b40  agent-code.zip

Download notiops-webchat.template.json only. The three .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is ~139 KB, above CloudFormation's
51,200-byte --template-body limit — from the CLI, upload it to S3 first and
pass --template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

NotiOps v1.0.11

NotiOps v1.0.11

One-click deployment grows up. v1.0.10 shipped the CloudFormation path with the
web chat only; this release makes the two capabilities that used to require a
local ./setup.sh run — deep root-cause investigation and multi-account
inspection — options you tick in the CloudFormation console. The default model
also changes to Grok 4.6, and three "deployed but confusing" failure modes now
say what is actually wrong. Existing deployments upgrade in place; both paths are
still supported and can be run one after the other on the same account.

⚠️ Sample/reference code, not a production-ready product. Review it with your
own security, legal, and compliance teams before deploying into an AWS account.

Features

• Deep investigation is created for you, and it is on by default. The stack
  now creates an AWS DevOps Agent Agent Space and wires the agent to it, so
  "investigate the root cause of this" works right after
  CREATE_COMPLETE instead of requiring a console visit and a manual space id.
  Controlled by the new EnableDeepInvestigation parameter (default Yes).

  • Billed per agent-second only while an investigation runs; an idle Agent Space
    costs nothing. Set it to No if you would rather not create the resource.
  • AWS DevOps Agent is not available in every Region yet. In an unsupported
    Region the space is silently skipped — the stack still reaches
    CREATE_COMPLETE and everything else works, rather than failing the whole
    deployment over an optional feature. Supported at the time of this release:
    us-east-1, us-west-2, ca-central-1, sa-east-1, ap-south-1,
    ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1,
    eu-west-1, eu-west-2.
  • The new DeepInvestigationStatus stack output always tells you which of the
    three states you are in — enabled, skipped because of the Region, or off
    because you chose No. "The toggle is missing from the UI" and "this Region
    cannot do it" look identical from the chat window, which is why the status is
    an unconditional output.

• Multi-account inspection from the template. The new DeployMode parameter
  (SingleAccount | MultiAccount) plus OrganizationId lets one stack cover
  an AWS Organization. In MultiAccount the stack creates the member-onboarding
  StackSets, and you then onboard accounts one click at a time from the admin
  panel.

  • MultiAccount requires that you deploy into the organization management
    account (or a CloudFormation StackSets delegated administrator) and that
    you fill in OrganizationId — it scopes the cross-account trust policies to
    your organization via aws:PrincipalOrgID. Leaving the id blank is not
    merely inconvenient: multi-account stays off, and the DeployModeStatus
    output says so.
  • Deleting the stack does not delete those StackSets or the roles they
    created in member accounts. DeployModeStatus states this too — deleting a
    stack and silently leaving IAM roles behind in other accounts is not
    something to learn later.

• Default model is now Grok 4.6 (global.xai.grok-4.6), replacing Claude
  Sonnet 5. This is the catalogue default introduced in v1.0.9, so it is one seed
  value, applied consistently: interactive chat, the non-interactive backend
  tasks (notification summaries and the like), and the documentation now all name
  the same model. Existing deployments are unaffected unless you re-seed —
  setup.sh will not overwrite a catalogue you have already customized — and any
  operator can pick a different default in Admin → Models without a redeploy.

Fixes

• A failed model call no longer renders as "(no response)". When the agent
  runtime hit an error mid-stream it emitted an error frame and then closed the
  stream normally (the HTTP response had already been a 200), which the front end
  read as "the model had nothing to say". Streamed failures are now surfaced as a
  readable explanation of what failed.

• The deep-investigation toggle is greyed out when the deployment cannot do
  it, with the reason stated, instead of offering a switch that is guaranteed to
  fail — for example when no Agent Space exists or the Region does not support
  one.

• Accounts that cannot open support cases now say so up front. Creating a
  case requires a Business or Enterprise Support plan; the check used to happen
  at submit time, so you filled in the whole form before being told. The
  limitation is now stated before you start.

• AgentCore idle session timeout is set explicitly to 3600s in the one-click
  template. The 900s default cut long-running sessions short.

Docs

• The README (both languages) gains an "Upgrade to a new version" / "Delete the
  whole environment" section — for both deployment paths, including what is
  retained on delete and what has to be removed by hand.
• A feature-by-feature setup.sh vs one-click comparison table, so the choice
  between the two paths is a table lookup rather than a reading exercise.

Tests and CI

The Python test suite is now actually run in CI. tests/ held 68 files of which
the pipeline executed 2 — the rest passed or failed depending on whether someone
ran them locally. All of them now run on every pipeline (911 tests at the time of
this release), alongside new suites covering the organization-mode stager path
and the support-case capability check.

Upgrading

One-click (CloudFormation): download notiops-webchat.template.json from the
assets below, then in the CloudFormation console update your existing stack with
it (Replace existing template). The new parameters default to
EnableDeepInvestigation=Yes and DeployMode=SingleAccount, so an update with
otherwise unchanged parameters adds the Agent Space and changes nothing else.
Measured at about a minute, because the new release's artifacts have to be staged
into your account again.

setup.sh:

git pull            # or re-clone at tag v1.0.11
./setup.sh          # re-run; existing resources are updated in place

Your data is not touched by either path: the conversation and configuration
tables are Retain, and re-seeding is idempotent.

Do not mix assets across releases — the template and the three .zip files are
cryptographically bound (each checksum is baked into the template and the release
tag is part of every object key), and the stack verifies every checksum before
use.

Asset checksums (sha256)

6d9bcd44c29325e37a78e4edf6fbae7515aed63ce1ac36300ebed6d0fde0c78b  bff.zip
92bc5a7d84073e6d4f59c540ff4d7969826c2190eaf3d11bd71fb67e9140e35c  chat-dist.zip
3738df016827001cb310b7c84e1ca50d00b60adc2f29413404978392e5e09ced  agent-code.zip

Download notiops-webchat.template.json only. The three .zip assets are
pulled into a bucket in your account by the stack itself; you never need to
download them by hand. The template is ~139 KB, above CloudFormation's
51,200-byte --template-body limit — from the CLI, upload it to S3 first and
pass --template-url.

See README for full setup, one-click deployment
for the console walkthrough, and the documentation for architecture
and operations.

v1.0.10 — one-click CloudFormation deployment

New: one-click deployment (CloudFormation)

This release adds a second deployment path: a single CloudFormation template.
No local toolchain, no long-lived access keys — a browser is all you need.

Download notiops-webchat.template.json only. The three .zip assets are
pulled into a bucket in your account automatically by the stack. You never
need to download them by hand.

1. Download notiops-webchat.template.json from the assets below.
2. CloudFormation console → Create stack → Upload a template file.
3. Fill in AdminEmail, tick the IAM acknowledgement, create — measured at ~4.5 minutes.
4. The stack outputs contain the Web Chat URL. Sign in as admin with the temporary
   password mailed to AdminEmail (check the junk folder — the sender is
   no-reply@verificationemail.com).

Full walkthrough, cost breakdown, upgrade/rollback and one-click teardown:
docs/DEPLOYMENT_ONECLICK.en.md
· 中文

Scope

Included — Web Chat (chat UI + BFF + Bedrock AgentCore agent, read-only by design),
FinOps dashboard on Cost Explorer data, AWS Support case management, AWS documentation Q&A.

Not included — Slack / Feishu bots, scheduled inspections, the admin dashboard,
CUR + Athena billing-detail drill-down, cross-account inspection. For those, use
./setup.sh — see docs/DEPLOYMENT.en.md.
The two paths can be run one after the other on the same account.

Before you create the stack

• Enable Bedrock model access for the Claude models in your chosen region
  (us-east-1 or us-west-2 recommended). Without it the stack still reaches
  CREATE_COMPLETE and you can log in, but every question fails with
  AccessDeniedException — the most common "deployed but unusable".
• The account needs egress to github.com so the stack can fetch these assets. If your
  egress allowlist blocks it, mirror the assets to a private S3 bucket and use the
  ArtifactBaseUrl + ArtifactMirrorBucket parameters — see §7 of the deployment guide.
• Tick "I acknowledge that AWS CloudFormation might create IAM resources".
• The template is ~93 KB, above CloudFormation's 51,200-byte --template-body limit.
  From the CLI, upload it to S3 first and pass --template-url.

Asset checksums (sha256)

0b8f5db42a6f91a6585ff50c8021f99f93f97119f835cc6a754061b8a0b259ae  bff.zip
0fffa7a49cc1e36aa7a6d3f6e1843899a2874979f3cb4e7474c2ecd9fb82b7a8  chat-dist.zip
86e3b2a12db85e667e2483dc1bbe786ebdee78476480b0777b4692d8520f3e91  agent-code.zip

The template and the three zips are cryptographically bound to each other (the checksums
are baked into the template, and the release tag is part of each object key). Do not mix
assets across releases — the stack verifies every checksum before use.

Everything else in this release

See the file diff against v1.0.9.

---

⚠️ This is sample code, for non-production usage. Work with your security and legal teams
to meet your organizational security, regulatory and compliance requirements before deployment.