This is very similar to a game I learned from my father as "Jotto". There are a number of differences between this and jotto, however, and they make this difficult for me to think about well, as they are fundamental. first of all, in jotto, "TASTE" and "TESTS" would score 4 -- 2 T's, 1 E, 1 S. Not knowing about doubled letters makes it much harder, i think.

Also, it's a game, as i learned it. so, you think of a mystery word, and i think of a mystery word, and we take turns guessing clue words and answering with the score. (So if i think of GLYPH and you ask "FIGHT" I'll respond "2.") and we continue until one of us solves the others word. that person is the winner. (Geting control over the clues makes it a lot more interesting to me.)

As a puzzle, it presents an interesting bad assumption in the first challenge -- what if a puzzle is not solvable? for instance, LIGHT : 4 BLACK : 0 well, it could still be Eight, Fight, Might, Night, Right, Sight, Tight... even Ghoti. so, should the script produce all possible answers, even if the data give does not narrow it down much?

as for "creating a puzzle"... well, there are all kinds of problems with trying to create a good puzzle algorithmically, but certainly you could keep adding random guesses until you had added enough that the word was obviously unique -- but then I would want to go back and weed out the guesses (or "clues") that didn't add any data.

anyway, the upshot of all this is that the way i would approach the problem would be to set it up like the game -- i'd create a responder (which would just mindlessly compare clue & word and report the commonality -- i can't think of an efficient way to do this, but i can certainly think of ways to do it). then I'd create a guesser that, given a history of other guesses, would pick a new guess.

(Apparently, Dad at some point wrote a program that brute-forced its way into playing the game, but I never saw the code. What I know of it was that it basically just picked a random word from the dictionary that could possibly be correct (meaning none of the clues conflicted with it). I don't know how efficiently it did this, though.)

anyway, you could try to have a little logic in there that "thought" about the clues, but that's really hard. You can make a career out of writing software to apply first-order logic. (one letter of BLACK but none of LABEL so C xor K; one of SITES and one of KITES so not K, so C. ... this is a lot easier for me to do than to code.)

on the other hand, for smplicity but brute force, you could jsut step alphabetically through the dictionary, toss out words that aren't the right length, and compare words that are against your list of clues. if it ever fails, throw it out. if it doesn't, add it to your list of possible solutions.

you probably want something between the two extremes. possibly you can immediately skip words containing letters you have ruled out, where by letters you have ruled out i mean letters contained in clues for which the answer was "0" -- but if your puzle doesn't have any such clues, you have problems. Also, you could make a couple passes at simple logical comparisons and try to distill some simple tests you coudl compare words to, without trying to solve the whole thing by logic. say, maybe BLACK = 1 and LOCAL = 1 so either A, C, L, or O-and-B or O-and-K. but makign this be worthwhile sees to me like it will be hard.

Just my thoughts,
Vynce
.