Connect configuration, delivery and audit to one revision
A fictional neighborhood repair center is splitting its reservation system into a Spring Boot service and a browser frontend. Two services need the same appointment configuration, so the team is considering a reusable starter. It also wants build, test and release evidence that another maintainer can follow. The goal is to automate repeatable work and preserve decision evidence, rather than treating generated YAML as proof of a successful deployment. Record Java and Spring Boot versions, the Maven or Gradle wrapper, frontend runtime and lockfile, database version, workflow platform and target environment. An existing Boot 3 application should use its matching documentation; adopting a template is not a reason to upgrade a framework major version. The following scenarios are operating methods. No reader repository was built, scanned or deployed for this article.
Scenario one: make auto-configuration a tested contract
Start with the appointment configuration contract: activation conditions, defaults, required properties, environment differences and beans consumers may replace. Group related properties and validate them rather than distributing unexplained defaults across the application. Document secret names and retrieval methods without putting real values in source, examples or logs. Confirm that repeated consumers and a stable boundary justify a starter before adding a library maintenance obligation. Separate configuration responsibilities from business behavior. Auto-configuration should supply a default implementation under stated conditions and allow an intended consumer override. For the existing Boot 3 project, check the auto-configuration imports resource and confirm it is present in the packaged jar. A resource visible in the source tree does not prove that publication included it. Do not conceal a registration problem by scanning an entire external package or by copying a registration mechanism from another framework generation. Design four context cases: matching conditions create the default service; explicitly disabled functionality does not; a consumer implementation causes the default to back off; invalid properties fail with an understandable explanation. Fixtures must not connect to production services. Use the version-matched official guidance to select a context testing approach such as ApplicationContextRunner, then verify packaging and dependencies in a separate minimal consumer. Testing only inside the starter's own build can miss consumer integration failures. When a bean is absent, inspect consumer dependencies, registration resources, condition outcomes, property names, active configuration and override behavior in that order. Absence can be intended backoff rather than a defect. Preserve negative conditions and failure reasons instead of adding annotations until startup happens to succeed. A successful startup still does not establish that the service selected the intended implementation. Deliver the property contract, module relationship, minimal consumer, results for the four cases and unsupported version boundaries. Slot capacity belongs to server-side validation, not a frontend default. If browser and backend disagree about dates or time zones, define the conversion point in the API contract and use boundary-date fixtures. Sharing configuration should not distribute the same mistake to every consumer. This article does not link an unverified same-named SkillPI package as a complete Java development capability. Spring's official documentation and the spring-projects/spring-boot source are the primary open source references because they expose the relevant implementation and version guidance. The agent may help explain or edit code, but each conclusion still needs evidence from the actual project.
Scenario two: move from reproducible build to controlled delivery
Write down local commands and success conditions before asking for a platform configuration. Use the build tool the project actually owns, identify integration-test services and frontend entry points, and locate the expected artifacts. Do not mix Maven and Gradle because a template includes both. Stages may cover checks, tests, packaging, release candidate and deployment, without rebuilding identical outputs merely to satisfy a diagram. The repair center's PR workflow should start with non-sensitive fixtures and a bounded test environment. Configuration tests, API tests and frontend checks should report their own outcomes. A tool that cannot start is incomplete, not a zero-finding success. Preserve the commit, build parameters, dependency resolution information and artifact digest for a release candidate. Deploy the artifact that passed verification instead of rebuilding an untraceable replacement during deployment. Review generated workflow configuration for triggers, working directories, runtimes, cache keys, permissions, secret references and report retention. Cache policy should consider build-file and environment changes; a cache hit is not a passed test. Third-party actions and base images need traceable references, source review and an update process. Pinning identifies code but does not prove that the code is trustworthy. Untrusted external PR code must not gain deployment secrets for debugging convenience, and failure artifacts must not disclose credentials. Continuous delivery can retain a deliberate approval step. Continuous deployment does not mean every revision bypasses protection. Before release, agree on environment, database migration behavior, health checks, observation window and rollback conditions. Rolling back an application artifact does not automatically reverse database changes. Destructive schema changes require an explicit compatibility and recovery design. These instructions do not authorize changes to a real account or production server. For the browser acceptance step, Webapp Testing is a matching verified skill. Its public SkillPI listing, pinned Anthropic source and Apache-2.0 license have been checked. It supports Python Playwright work against a running local webpage, including interaction, screenshots and logs. Prerequisites include backend and frontend startup commands, ports, a test identity and non-sensitive fixtures. It does not build a Java starter, replace API integration tests or prove database persistence. Browser cases can cover slot display, submission validation, retained input after a service error and feedback for repeated activation. Capacity under concurrency, persistence and transactions need backend evidence. Deliver workflow files, necessary container-build notes, environment inventory, actual trial results and rollback instructions. If the work only generated configuration, say that remote execution is unverified rather than calling the pipeline end-to-end tested.
Scenario three: audit by language and risk
Inventory Java, frontend code, Python utilities and configuration before choosing analyzers. npm and pip audits do not establish coverage of Maven or Gradle dependencies. A Python-oriented analyzer cannot substitute for Java analysis. Record resolved dependencies, advisory source, tool version and supported inputs separately for each ecosystem. Avoid an all-stack scanning claim that hides gaps. Organize findings into dependency risk, secret exposure, code data flow and engineering rules. For dependencies, record package, resolved version, advisory, proposed remediation and deployment relevance. For suspected secrets, retain a redacted fingerprint, location and containment owner. An authorized owner should promptly revoke or rotate a potentially live exposed credential rather than waiting for a complete scan. Removing source text does not remove history or external copies and does not invalidate the credential. Trace concrete input paths to queries, output and authorization boundaries. For example, when a reservation note influences a query, inspect parameterization and the construction of dynamic structure. When the note is displayed, inspect rendering and output context. Reachable data flow matters more than a keyword. Seeing a particular API name does not by itself establish SQL injection or XSS, and framework use does not establish immunity. For each finding, preserve revision, file location, reproduction conditions, evidence, impact, severity rationale, a minimal correction and retest outcome. Separate confirmed defects from risks awaiting validation. Tool findings require interpretation and human conclusions require evidence. Generated code, external services, runtime privileges and unavailable deployment configuration belong in the coverage limits, not in an assumed pass category. Code scanning and organizational compliance are different layers. If the project needs a framework mapping, responsible reviewers must establish applicable scope, control objectives, evidence and ownership. Technical findings contribute to that work. A command does not prove conformity with GDPR, SOC 2 or another framework, and a shared numerical score cannot replace a full assessment. This article makes no legal compliance determination. Deliver a coverage matrix, severity-ranked findings, remediation plan and retest record. A gate should distinguish policy pass, blocking findings and incomplete scanning. Advisory-service failures and parsing errors must not become green zero-finding results. Exceptions need reasons, scope, owners and expiry. Lower-severity items still need sensible treatment rather than indefinite blanket suppression.
A practical task brief
“Within this application's existing version range, design reusable appointment configuration. List properties and conditions first, then propose four context cases and a separate consumer fixture. Generate one pipeline from the repository's real commands and retain permission and environment boundaries. Separate audit coverage for Java, frontend and helper scripts. Inspect read-only before proposing minimal changes. Do not upgrade the framework, validate leaked credentials over the network, change organization protections or deploy production.” Require the handoff to distinguish design from actual execution. Accept the work by checking that the consumer uses the real candidate package, that test records match the revision, and that browser and database evidence each support the behavior claimed. Store logs, inventories and findings in controlled locations. Do not copy personal data or credentials into public issues just to make the review convenient.
Troubleshooting and FAQ
Properties are missing: inspect property sources, keys, active configuration, binding and validation before changing conditions. Removing validation merely to make startup succeed conceals the defect. Local builds pass but CI fails: compare Java, wrapper, directory, permissions, dependency repositories and required services at the failing stage. Skipping tests should not be the default repair. Deployment reports success but the page fails: inspect service health, entry routing, browser requests and backend state separately. Uploading an artifact is not acceptance of a user journey. An agent can generate candidate YAML, but its permissions and execution prerequisites still need review and a controlled trial. A success log for packaging cannot prove that a migration or reservation transaction worked. How should scanners be selected? Start with input support and the risk question, then evaluate version, documentation, licensing, dependencies and external data transfer. A package useful for Python scripts may cover those scripts while leaving the Java service unexamined. Record that distinction instead of promoting a partial result into a repository-wide assurance claim. What if a matching skill is unavailable? Existing tools, official documentation and a bounded request may be adequate. Do not add irrelevant links to fill a quota. If discovery is necessary, verify the official SkillPI Skill Finder source and prerequisites, then inspect each candidate's pinned package and actual purpose. Discovery does not guarantee that every candidate is free, safe or ready for the current runtime. When should associations change? Revisit public availability, source differences and step-specific fit as the catalog grows. Record dates and replacement reasons. The linked browser skill remains restricted to frontend journeys; a future Java or delivery skill must be independently verified before association.
Sources and evidence boundary
The originals cover Spring Boot auto-configuration and starters, CI/CD orchestration, code audit and FAQ. Those scenarios remain separate here, with original fixtures and concrete deliverables. References are version-matched Spring Boot auto-configuration documentation, Spring's open source implementation, GitHub's secure Actions guidance and the linked skill's pinned source. Anonymous anecdotes, install counts, generic security-review guarantees and promises of intervention-free production delivery are omitted. This guide provides design and acceptance methods, not a report that a real business system was built, scanned or released.