Updated readme

Author: phate999

.github/workflows/build-containers.yml

@@ -16,6 +16,16 @@ name: Build and Publish Containers
 # the package's GitHub page -> Package settings -> Change visibility ->
 # Public. This has to be done once per container image; it is not something
 # the GITHUB_TOKEN used here is allowed to do on its own.
+#
+# This step needs ADMIN permission on the package specifically, not just
+# Write access to the repo. A package inherits its access permissions from
+# the linked repo by default, and changing a package's visibility requires
+# admin on that package -- observed directly: a contributor with Write access
+# to this repo (enough to merge the PR that adds this workflow) got "You
+# don't have access to repository options" on the repo's own Settings page,
+# which is the same permission boundary that blocks the package visibility
+# control. Confirm who has org-owner or repo-admin rights before assuming
+# whoever merges this can also complete the visibility flip themselves.
 
 on:
   push:

.kiro/steering/container-building.md

@@ -92,7 +92,7 @@ Follow these conventions established in this repo:
    - Add `/udp` to port mappings for UDP services
    - **Pick one separator (hyphen or underscore) for the sample's name and use it verbatim everywhere the name appears**: the directory, the Dockerfile's `CP_APP_NAME`, the compose `service:`/`container_name:`, the built and pushed image name in every code block across the README, and any `container logs <name>` example. A pushed tag that differs from the deployed `image:` value by nothing more than `-` vs `_` produces `unauthorized`/`denied` pull errors that look exactly like a registry permissions problem, with nothing in the error text pointing at the name mismatch. When a README shows the image name in more than one place (Building and Deployment sections, for example), grep the finished file for the name and confirm every occurrence is byte-identical before finishing — this is a cheap, mechanical check worth doing every time, not just when something breaks.
    - The NCOS-deployment example's `image:` must reference this sample's own build, e.g. `yourregistry/<sample>:latest` — never a third party's public registry image, even one that happens to already exist and work. A vendored example is copied verbatim more often than it is read carefully, so a stray third-party reference propagates further than a one-off mistake would
-   - When the container wraps an off-the-shelf binary or daemon that has its own security features (auth, TLS), wire those through as environment variables or config rather than adding a second layer in front of it. Read that binary's own documentation for security-relevant defaults, not just feature flags — e.g. an auth bypass for requests it treats as coming from localhost is a real gap for anything else in the same network namespace, and would be missed by testing only the published port
+   - When the container wraps an off-the-shelf binary or daemon that has its own security features (auth, TLS), wire those through as environment variables or config rather than adding a second layer in front of it. Read that binary's own documentation for security-relevant defaults, not just feature flags — e.g. an auth bypass for requests it treats as coming from localhost is a real gap for anything else in the same network namespace, and would be missed by testing only the published port. **Settle security-relevant behaviour from the source at the version the Dockerfile pins, not from upstream's current docs** (which describe the newest release, not the pin), and **enumerate it per listener, module and endpoint** — a daemon with several listeners often has different auth semantics on each, including one with a hardening option and another with no equivalent, so any single sentence about "the daemon" will be wrong about at least one of them. Config struct tags enumerate what the config accepts, which prose does not; `strings` on the release binary usually does not, since many projects ship UPX-packed builds. Record the version alongside the claim, the same way a router probe result is recorded with model and firmware. See "Verify a Wrapped Binary's Behaviour From Its Source at the Pinned Tag" in `docs/container-development-guide.md`
 
 5. **Architecture**:
    - ARMv7 32-bit: AER2200, IBR1700
@@ -108,7 +108,9 @@ Removing a feature is not the inverse of adding one, and the surface is wider th
 4. **Read the container's own startup log after a rename.** Operator-facing strings — banners, log prefixes, server headers, error text — are invisible to behavioural tests, which assert what the code does and not what it calls itself.
 5. **Check whether the removed code was the only demonstration of a shared capability.** In a sample repo the code is the documentation, so losing the sole example of an SDK function is a real coverage gap. Say so rather than letting it disappear silently.
 6. **Do not re-add scope while simplifying.** If a simplification leaves a gap, report it and let the user decide instead of quietly reintroducing what was just removed.
-7. Finish by updating the sample's README in the same change, and re-grep the whole repo including `docs/` for the old name.
+7. **Fixing a documentation error means correcting the document.** A wrong doc can be resolved two ways — correct the prose to describe the code, or change the code so the prose becomes true — and "this README is wrong, fix it" asks for the first. Changing an entrypoint, a config example or a compose file so that the documentation you would prefer to write becomes accurate is a different task with a much larger blast radius, and it needs its own consent. If the audit surfaces something better fixed in code, report it as a finding. This holds especially when you have already told the user in a previous turn that such a change would be separate: **acceptance of the in-scope offer is not consent to the item you yourself set aside**, and your own earlier message is the record that you knew the difference.
+8. **Order a multi-file edit so the file the user actually named changes first.** An interruption then leaves work that is a subset of the request rather than disjoint from it — doing the peripheral files first and the requested one last means an aborted turn shows only unrequested changes, which reads as wilful rather than incomplete. Related: after any interruption or user correction, run `git status --porcelain` and `git diff --stat` on the affected directory before describing what you did. An aborted tool call means the files you intended to change and the files you actually changed are different sets, and a summary written from memory will be confidently wrong.
+9. Finish by updating the sample's README in the same change, and re-grep the whole repo including `docs/` for the old name.
 
 ## Phase 2b: Verify Before Declaring Done