Skip to content

sharukhan phase-0: scaffold SDD artifacts - #319

Closed
dcasota wants to merge 1 commit into
masterfrom
sdd/sharukhan-phase-0-init
Closed

sharukhan phase-0: scaffold SDD artifacts#319
dcasota wants to merge 1 commit into
masterfrom
sdd/sharukhan-phase-0-init

Conversation

@dcasota

@dcasota dcasota commented Aug 31, 2026

Copy link
Copy Markdown
Owner

Phase 0 of a new SDD-tracked subproject: a single standalone Rust CLI, sharukhan, replacing the shell tooling in staging/vm-lab and staging/mission-control.

Per specs/README.md the phases gate each other via merged PRs, so this PR only makes the subproject ready to receive specs. No src/ in this PR — implementation is blocked until the PRD merges.

What is here

File Purpose
specs/README.md layout table, 7-phase workflow, identifier chain, quality gates, branch/commit convention
ARCHITECTURE.md why one binary, the layer diagram, the axis model, memory-database entities, security posture, Open Initiatives
AGENTS.md role boundaries and Rust standards

Convention followed, not invented

Layout and workflow mirror tdnf-depgraph/specs/ — the same prd.md / adr/NNNN-<slug>.md / features/<slug>.md / tasks/NNN-task-<slug>.md / findings/ set, sdd/<initiative>-phase-N-<slug> branches, and <subproject> phase-N task NNN: <imperative> commit subjects. The quality gates are restated in Rust terms (cargo test, cargo clippy -- -D warnings, cargo fmt --check, ≥80% coverage — the in-repo precedent) because those differ by toolchain.

One thing worth flagging

Neither nominated SDD source contains a constitution file. There is no constitution.md, no memory/, no .specify/ in either vCenter-CVE-drift-analyzer or sitoader/SDD-book-tracking-app. The AGENTS.md the latter references is generated by an Azure-centric APM toolchain (apm install && apm compile) and is not committed there.

So the AGENTS.md in this PR was authored by hand for Rust, and both it and specs/README.md say so explicitly. I would rather state that plainly than present an invented file as an inherited standard.

Why one binary

ARCHITECTURE.md records three observed problems in the tooling being replaced, not hypothesised ones:

  • Implicit input resolutionrunPh5_normal.sh resolves its patch relative to its own location; the two copies on this host had drifted 78 lines and 8-vs-27 files apart, and the build used whichever sat beside the invoked script. It surfaced as patch does not apply against a spec, which reads like a rebase problem.
  • Checks that cannot fail40-check-staging.sh never exits non-zero.
  • Silently vacuous pipelines/usr/bin/grep is toybox in a non-interactive shell and has no -a, returning zero matches on a NUL-bearing serial log; interactively the same name is ugrep. sed \U and grep -P are GNU-only and absent here.

It also records the axis model that makes 34 permutations cost 4 ISO builds: ISO type and installer version are build-time, while STIG, filesystem and kickstart-vs-UI are free, because isoInstaller reads guestinfo.kickstart.data through vmtoolsd and vmtoolsd is present in the installer initrd.

Next: specs/prd.md on sdd/sharukhan-phase-1-prd.

Creates the subproject skeleton so it can receive specs, following the
convention already live in this repository (tdnf-depgraph, docsystem,
vCenter-CVE-drift-analyzer): specs/{README,prd,adr,features,tasks,findings},
sdd/<initiative>-phase-N-<slug> branches, and
'<subproject> phase-N task NNN: <summary>' commit subjects.

ARCHITECTURE.md records why this is one binary rather than more shell: the
tooling it replaces resolved inputs implicitly (two downstream-fixes.patch
copies drifted 78 lines and 8-vs-27 files apart, and the build silently used
whichever sat beside the invoked script), had checks that could not fail
(40-check-staging.sh never exits non-zero), and rested on pipelines that can
be silently vacuous (/usr/bin/grep is toybox non-interactively and has no -a,
returning zero matches on a NUL-bearing serial log).

It also records the axis model that makes 34 permutations cost 4 ISO builds:
ISO type and installer version are build-time, while STIG, filesystem and
kickstart-vs-UI are free because isoInstaller reads guestinfo.kickstart.data
via vmtoolsd, which is present in the installer initrd.

AGENTS.md is authored by hand and says so. Neither nominated SDD source
contains a constitution file; the AGENTS.md that SDD-book-tracking-app
references is generated by an Azure-centric APM toolchain and is not
committed there, so nothing here is inherited or generated.

Signed-off-by: Daniel Casota <dcasota@gmail.com>
dcasota pushed a commit that referenced this pull request Sep 9, 2026
…facts

PRs #319/#320 proposed staging/sharukhan/ while the CLI lives at
staging/sharukhan-cli/ - two directories that were never reconciled, which is
why both carried a PRD. This lands their content in the CLI's own tree and
adopts the convention the four sibling SDD subprojects already share
(tdnf-depgraph, docsystem, vCenter-CVE-drift-analyzer,
photon-gating-conflict-detection): specs/adr/NNNN-<slug>.md, plus features/,
tasks/, findings/, archive/.

  specs/adr-0001-run-stop-watch.md  ->  specs/adr/0001-run-stop-watch.md
  specs/prd.md (2863 b)             ->  specs/archive/prd-2026-08-initial.md

#320's PRD replaces it as specs/prd.md. It is the SDD-template form the
siblings use, and it is closer to the shipped tool - it names `run` 15 times
against 1, `build` 9 against 2, and mentions verify and canister at all. The
emoji was dropped from its title to match the house style. The short one is
archived rather than deleted; it is the earlier sketch, not wrong.

schema/memory.sql is NOT #320's copy. That one predates the schema: 6 tables,
no indexes, no views, no next_step. This is generated from the live database,
which matters more than it looks - src/memory.rs opens the database READ-ONLY
and never creates it, so until now nothing in the repository could recreate a
lost memory.db. Verified by applying it to an empty file: 14 objects, an
identical object set to the live database.

MEMORY.md is likewise regenerated rather than imported. #320's rendering shows
0 rows in every table; the live one has 121 runs, 3374 check results and 52
findings.

vm-lab (#316) is archived under superseded-vm-lab/ rather than dropped.
ARCHITECTURE.md names it as one of the two toolkits sharukhan replaces, and
mission-control's bash is already preserved the same way. ARCHIVE.md records
why it went, quoting the architecture's own verdict: 40-check-staging.sh never
exits non-zero, which is fine for an inspection tool and useless as a gate.

Path references in the imported prose were repointed to where the files now
actually live.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf
@dcasota

dcasota commented Sep 9, 2026

Copy link
Copy Markdown
Owner Author

Landed by another route — closing rather than merging.

The content of this PR is in master as of 812f4d8, under staging/sharukhan-cli/ rather than staging/sharukhan/:

this PR now
staging/sharukhan/AGENTS.md staging/sharukhan-cli/AGENTS.md
staging/sharukhan/ARCHITECTURE.md staging/sharukhan-cli/ARCHITECTURE.md
staging/sharukhan/specs/README.md staging/sharukhan-cli/specs/README.md

Why the move. This PR targeted staging/sharukhan/ while the CLI itself lives at staging/sharukhan-cli/ — two directories that were never reconciled, which is why both ended up carrying a PRD. The artifacts now sit in the CLI's own tree, and that tree adopted the layout the four sibling SDD subprojects already share (tdnf-depgraph, docsystem, vCenter-CVE-drift-analyzer, photon-gating-conflict-detection): specs/adr/NNNN-<slug>.md plus features/, tasks/, findings/, archive/.

The one pre-existing deviation was fixed at the same time — specs/adr-0001-run-stop-watch.md moved to specs/adr/0001-run-stop-watch.md.

Path references inside the imported prose were repointed to where the files actually live.

@dcasota dcasota closed this Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant