azaion/satellite-provider
1
0
Fork 0
mirror of https://github.com/azaion/satellite-provider.git synced 2026-06-21 20:31:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

[AZ-495] [AZ-496] Cycle 3 batch 1: doc convention + AspNetCore 8.0.25
ci/woodpecker/push/01-test Pipeline was successful
Details
ci/woodpecker/push/02-build-push Pipeline was successful
Details

Browse Source 
AZ-495 (1 SP): formalize the modules-only documentation convention for
the WebApi component. _docs/02_document/module-layout.md now carries an
explicit Documentation Layout section anchoring WebApi docs at
modules/api_program.md; the components/06_web_api/ folder is
intentionally absent. .cursor/skills/new-task/SKILL.md Step 4 directs
future agents at the correct path. Cycle-1 + cycle-2 F1 findings in the
two batch-review files are marked RESOLVED with back-reference to
AZ-495. Cycle-2 retrospective decision-item list F1 updated.

AZ-496 (2 SP): bump Microsoft.AspNetCore.OpenApi and JwtBearer in
SatelliteProvider.Api.csproj from 8.0.21 to 8.0.25, closing CVE-
2026-26130 (SignalR DoS - not reachable in this app, but the runtime
patch is the recommended hardening per cycle-1 D1 + cycle-2 D3).
SatelliteProvider.Tests.csproj has no direct JwtBearer reference - it
consumes JwtBearer transitively via ProjectReference to Api, so no
edit needed there. Dockerfiles use floating mcr.microsoft.com/
dotnet/aspnet:8.0 / sdk:8.0 / runtime:8.0 tags which auto-resolve to
>= 8.0.25 on rebuild. Security artifacts (dependency_scan.md,
security_report.md) and current-state docs (module-layout.md,
architecture.md, modules/api_program.md, modules/tests_unit.md)
updated to reflect 8.0.25.

Batch report + code review report (verdict PASS_WITH_WARNINGS with 2
Low findings, neither blocking) written under _docs/03_implementation.

Test suite gate deferred to Step 16 (Final Test Run) per implement
skill convention. Patch-level bump within .NET 8 LTS; regression risk
very low.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-12 01:24:48 +03:00
parent 76076cbd90
commit 9cfd80babe
15 changed files with 140 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.cursor/skills/new-task/SKILL.md
+3 -1
View File
@@ -136,9 +136,11 @@ The `<task_slug>` is a short kebab-case name derived from the feature descriptio
1. Read the codebase documentation from DOCUMENT_DIR:
- `architecture.md` — overall structure (the `## Architecture Vision` H2 is user-confirmed intent and must not be violated by the new task without explicit approval)
- `glossary.md` — project terminology; reuse the user's vocabulary in task names, AC, and component references
- `components/` — component specs
- `components/` — component specs (one folder per Layer-3 service component)
- `modules/` — process-level documentation (Layer-4 WebApi lives in `modules/api_program.md`, not in `components/`; see `module-layout.md` § Documentation Layout — AZ-495)
- `system-flows.md` — data flows (if exists)
- `data_model.md` — data model (if exists)
- When the task touches WebApi (`SatelliteProvider.Api`), the documentation anchor is `modules/api_program.md` — do NOT reference `components/01_web_api/description.md` or any `components/*/web_api*` path; that folder is intentionally absent per the AZ-495 convention.
2. If research was performed (Step 3), incorporate findings
3. Analyze and determine:
- Which existing components are affected