How to use globs in SpecDD

How-To Use spec sections Intermediate 1061024HOWTO-1061024

HOWTO-1061024Use spec sectionsIntermediate

This guide shows you how to use globs in SpecDD .sdd files.

Globs are path candidates that contain wildcard metacharacters. They are useful when a spec needs to describe a deliberate set of files, but broad globs can also make authority harder to review.

Short answer

Use globs with explicit path prefixes: ./, ../, or /. Keep patterns narrow, especially in Can modify, Owns, and Forbids. Use recursive ** only when recursive coverage is intentional. Malformed glob patterns are treated as warning-level unresolved glob issues, not syntax errors.

Supported glob constructs

Glob metacharacters:

*
?
[
]
{
}

Supported constructs:

*       zero or more characters within one path segment
?       exactly one character within one path segment
[abc]   character class
{a,b}   alternatives
**      zero or more characters across directory boundaries
**/     zero or more directories

Examples:

Can modify:
  ./fixtures/*.json

Can read:
  ../policies/**/*.sdd

Forbids:
  ../booking/*

Steps

1. Start with an explicit path prefix

Good:

Structure:
  ./src/**/*.ts

Weak:

Structure:
  src/**/*.ts

Unprefixed entries are text, not explicit path candidates.

2. Keep writable globs narrow

Acceptable when intentional:

Can modify:
  ./fixtures/*.json

Risky:

Can modify:
  ./**/*

Broad writable globs can authorize too much. Prefer exact files when the set is small.

3. Use recursive globs deliberately

A non-glob directory reference such as:

References:
  ../policies

should not recursively include every descendant spec. If recursive inclusion is intended, use an explicit glob:

References:
  ../policies/**/*.sdd

4. Match the section intent

Use globs by meaning:

Structure for layout
Owns for owned file sets
Can modify for writable file sets
Can read for readable context sets
References for related spec or doc sets
Forbids for blocked file sets

A glob in Can read is not writable authority. A glob in Forbids blocks matching paths.

5. Review glob changes carefully

Changing:

Can modify:
  ./fixtures/*.json

to:

Can modify:
  ./**/*.json

may expand write authority substantially. Treat broadening changes as review-worthy.

Common mistakes

Using globs without ./, ../, or /.
Using recursive ** when a shallow pattern would be enough.
Adding broad writable globs to avoid naming files.
Assuming malformed globs are hard syntax errors.
Treating a directory link as a recursive glob.
Forgetting that glob meaning depends on the section.

How to verify the result

Glob usage is safe when:

each pattern has an explicit prefix
each broad or recursive match is intentional
writable globs are narrow enough to review
forbidden globs match the intended blocked paths
reviewers can tell which files are likely covered

Language reference

← Use spec sections guides